❇️ دو محتوای آموزشی

🔶 سایت Pluralsight بیش از ۷۰۰۰ دوره خودشو رایگان کرد (تا پایان آپریل)
https://www.pluralsight.com/offer/2020/free-april-month

🔷 یه ریپازیتوری تو گیتهاب هست که لیستی از کتابهای رایگان برای زبان های مختلف برنامه نویسی رو گذاشته و من اومدم اوناییش که مرتبط با کارمون هست رو براتون لیست کردم
🔘 .NET Framework
🔘 C Sharp
🔘 ASP.NET
🔘 JavaScript
🔘 TypeScript
🔘 Angular
🔘 React / Redux
🔘 Web Performance
🔘 Security
🔘 SQL Server
🔘 NoSQL
🔘 Bash
🔘 PowerShell
🔘 Professional Development
🔘 Software Architecture
____________________
@DotNetZoom

ویدئو آموزشی کار با کتابخانه سیگنال گو و ساخت یک برنامه console
جهت ارتباطات دوطرفه کلاینت و سرور در سیستم عامل گنو لینوکس

ویدئوی آموزش سیگنالگو در لینوکس که توسط دوست و همکار عزیزم آقای سعید رضایی @mrgrayhat ساخته شده که میتونید توسط این آموزش یاد بگیرید که توی لینوکس چطوری یک سرور و کلاینت سیگنالگو رو با ویژوال استادیو کد و سیگنالگو کد جنریتور بسازید.

https://www.youtube.com/watch?v=WzbYpTiH2L8

Hey Guys, we started working on a strategic game project (Armageddon)
in my GitHub: https://github.com/mrgrayhat/ArmageddonGame

We are currently writing the core structure of the game. ant it's test's.
In the next, we will write the Console & Unity version of the Game (2D/3D).
We welcome your comments / idea's.🤙🏻🙏🏾

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

Publisher 2.1.4 Released (LTS)
Change Log:

* File Manager:
- Fixed Upload Edited file bug to Server.
* Access Control:
- Add Setting Ability to select the authentication step by the user.
By Default, Authentication is asked at the beginning of the command queue execution for easy to use.
You can disable it, in which case you will be asked whenever the command reaches and need the authentication stage.
Change it on:
Tools Menu -> Publisher Settings -> Command's Settings -> Authenticate At First

- Added Master Password For Publisher & Access Control Module.
You can activate Auto Access Control by the toggle button in the status bar of the program.
Once enabled, you do not need to enter a password to execute commands on protected server's, each time.
Otherwise you have to authenticate every time.
Set Master Password by:
Tools Menu -> Publisher Settings

Some improvements.

Server Manager 1.7 Released! (LTS)
* Important Notes:
- We Fixed some bug's which affected Service Manager And increased CPU consumption. Update for better performance And Stability.
* Fixed Stop Service And Process PIP Bug's while restarting and update. Sometimes it didn't work properly.
- Make Some Background Function's Async And Multithread.
- Added AutoStart Option For Service's. If you don't want an service to automatically start while server manager startup, just uncheck it in server info page and save!
-Some Improvment and Integrated With New Feature's added in Publisher 2.

Note: Update Server Manager To Latest Version To Use Publisher > 2.0 Features.

Publisher 2.1.5 Released (LTS)
Change Log:

* Access Control
- AC Authenticator Bug Fix.
(ask password for non protected server's in command runner)

Add "Empty to remove" and Hint Text param for in input dialog. (to remove stored secret for server's or master password, if you forgot).

The Box
Dusan Katelic

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

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

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


#ابله
#فئودور_داستایفسکی

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

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

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

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

با نوشتن سری مطالب کاربردی ای که حاصل تحقیق های مفصل و تجربه های کاری و شخصیم هست شروع کردم و انشالله منتشر میکنم.
شما هم اگر موضوعی رو مدنظر دارید میتونین مطرح کنین.

از سری مطالب معماری نرم افزار #1
بررسی اجمالی اصول طراحی و چرخه تولید نرم افزار ها

اگر هنرجو یا دانشجوی رشته مهندسی نرم افزار بوده باشید، حتما با رویکرد هایی که در آموزش برنامه نویسی و طراحی نرم افزار استفاده میشه آشنا هستین. اکثر شیوه های آموزشی در دانشگاه ها و آکادمی ها بیشتر جنبه آشنایی و تئوری دارن.
در فاز عملی، نحوه کدنویسی و مبانی پایه هر زبان آموزش داده میشه. مثلا الگوریتم، قواعد زبان c,c++ یا اخیرا c#، ساختمان داده و ازین دست مقوله ها. اگر کمی علمی تر باشه، شاید جنبه های چرخه تولید و نگهداری نرم افزار ها و رویکرد های تخصصی رو هم تا حدی بهش بپردازن. (اما چیزی که ما اکثرا دیدیم فقط یکسری کد و برنامه فاکتوریل و فیبوناچی و ستاره چاپ کن ... بوده)
در درجه اول این شما هستین که باید پیگیر موضوعات مختلف در علوم مهندسی نرم افزار باشین. پروتکل ها، پلتفرم ها، اصول و قواعد زبان های برنامه نویسی، همه در سطوح تئوری و تا حدودی عملی به شما معرفی میشن اما خیلی کمیاب و بعیده که به درون این مباحث هم بپردازن. (به قول استادی ما فقط استارت رو میزنیم، دیگه تهش یکم هل ات میدیم)
تایید حرف من رو میتونین در بین خیلی از دانشجوهای این رشته ببینید. حتی در بین برنامه نویس ها و تحصیل کرده های بازار کار این حوزه، هنوز عده کثیری درک درستی از ساختمان داده، الگوهای طراحی، اصول شئ گرایی و نرم افزار، به درستی ندارند. ضعف سیستم آموزشی ما بر هیچ کس پوشیده نیست، اما ضعف خود ما چی؟ چند درصد دانشجو ها و مهندس ها واقعا به دنبال یادگیری بیشتر و کسب تجربه میرن؟ (مطمئنم دلیل اینکه هی میگفتن رشته کامپیوتر اشباع شده رو الان بهتر درک میکنین، از جک هایی که راجع بهمون میگن که دیگه نگم براتون :D )

یکی از صدها موضوع فوق العاده مهم در علم مهندسی نرم افزار، معماری نرم افزار هست. به رشته های مکانیک، ساختمان و معماری نگاه کنید. صرفا داشتن ابزار و اطلاعات کمک کننده نیست. قبل از ساخت یک ساختمان، ابتدا نقشه منطقه و ساختمان، زیر ساخت ها، امکانات و نیازمندی ها و ... آماده میشه و بعد شروع به ساخت و ساز میکنن. مطمئنا اگر وسط ساخت و ساز به فکر تغییر ابعاد خانه یا رفع ناهماهنگی بین سازه ها و اجزای ساختمان باشین، تمام وقت و سرمایه خودتون و دیگران رو هدر خواهید داد و چه بسا خشت اول رو که کج بزارین، تا آخر کج خواهید رفت!
پس قبل از پلن پیاده سازی، باید بدونید چی نیاز دارین و چطور میخواین انجامش بدین، کدنویسی یک مهارته، فراتر از اون معماری و معماری طراحی هست (منظور دیزاین نیست) . به همین خاطر شما میتونید تنها یک معمار نرم افزار باشید چون خودش تخصص جداگانه ای هست که راحت کسب نمیشه. میتونید فقط یک کدنویس باشید که طبق معماری و خواسته های طراح و مدیر پروژه با سابقه ای پیاده سازی کنید.
طراحی نرم افزار مباحث زیادی داره که من فعلا موضوع معماری های نرم افزار رو مدنظر گرفتم.
*نکته مهم*
مباحث معماری نرم افزار، الگوی معماری نرم افزار و الگوی طراحی نرم افزار، سه مبحث کاملا متفاوت و بنیادی در مهندسی نرم افزار و برنامه نویسی است. گاها این سه مقوله یکسان در نظر گرفته میشن یا با هم اشتباه گرفته میشن. (خیلی جاها هم اصلا مفهوم معماری دیده نمیشه و فقط کدهای متعدد و لایه بندی های زیاد میبینیم بعد میگن معماریمون n-layer یا DDD عه! )
معماری و الگوهای استفاده شده در نرم افزار، پیاده سازی، آینده توسعه و نگهداری و استفاده از نرم افزار رو رقم میزنه. اینکه یک سامانه متشکل از صدها سرویس و هزاران کاربر چطور طراحی و پیاده سازی بشه تاثیر مستقیم در موفقیت تیم شما و محصول شما داره. معماری و تحلیل تکنیکال مناسب، تاثیر زیادی در صرفه جویی هزینه ها و زمان شما و تیم تون داره. همچنین میتونه تضمین کنه که تغییرات و اتفاقات آینده، با مناسب ترین هزینه و زمان به شیوه مشخص و بهینه ای قادر به انجام خواهند بود.
در مطلب بعدی درباره هر سه موضوع نام برده، توضیح میدم.
@csharpfriends #SoftwareEngineering #SoftwareArchitecture #SoftwareLifeCycle

از سری مطالب معماری و مهندسی نرم افزار #2

مفاهیمی در معماری نرم افزار خیلی وقت ها کج فهمیده میشه و در این مطلب سعی میکنم این موضوع رو کمی تشریح کنم.
1. معماری نرم افزار (Software Architecture):
معماری نرم افزار به موضوع شناخت و ترسیم کلیت نرم افزار و شکستن کل به بخش های مختلف، رفتارها و ارتباطاتش با دیگر اجزا مانند سرویس ها و برنامه های خارجی، دیتابیس، سرور ها و زیر ساخت ها می پردازد.
همچنین دید کلی از سامانه های نرم افزاری، شبکه ارتباطات داخلی و خارجی(external)، نگهداری و توسعه نرم افزار ها که ارتباط تنگاتنگی با معماری استفاده شده در نرم افزار ها دارد. به طور ساده تر و خلاصه تعریف معماری نرم افزار رو میتونیم به شکل: نقشه ای برای مدیریت پیچیدگی ها/نیازمندی های سیستم و ایجاد ارتباط و هماهنگی بین بخش های مختلف بیان کرد.

از معروف ترین معماری های نرم افزار، میتوان موارد زیر را نام برد:
معماری یکپارچه یا Monolithic
معماری سرویس گرا/مبتتنی بر سرویس یا SOA
معماری میکروسرویس یا Microservice

2. الگوی معماری نرم افزار (Software Architecture Pattern):
الگوهای معماری نرم افزار، جهت جداسازی منطق و ساختار لایه های مختلف، قابلیت استفاده مجدد و توسعه آنها استفاده میشوند. تعیین پروتکل های ارتباطی و منطق لایه های مختلف مانند لایه Presentation، دیتابیس و دسترسی به داده، سرویس ها و ... از خواص الگوی معماری انتخاب شده ارث میبرند. در واقع آنها روش هایی برای کمک به مشکلات و نیاز های مربوط به طراحی نرم افزار ارائه میدهند.
خیلی ها معماری و الگوی معماری نرم افزار را یکسان تلقی میکنن. در آموزش ها، مقالات و وبسایت ها اغلب یا به اشتباه توضیح داده میشن یا به یکسان. شیوه و روش طراحی نرم افزار، با معماری کل نرم افزار تفاوت دارد. به نما و کلیت معماری ساختمان، ساختار و سازه های داخلی و نحوه ارتباط اجزا مختلف و استفاده اونها فکر کنید. به سیم کشی ها و پیچیدگی های مخفی شده در بین سازه ها و ارتباط دیوارها و ستون ها، نحوه باز شدن درب و پنجره و .. اینها یکسان هستند؟!

برخی از پرکاربرد ترین الگوهای معماری نرم افزار(Architectural Patterns) :
- الگوی سه لایه و چند لایه 3Layer & N-Layer و n-Tire
- الگوی MVC (Model View Controller)
- الگوی MVP (Model View Presenter)
- الگوی MVVM (Model View Viewmodel)

رویکرد طراحی دامنه محور یا Domain Driven Design، به اختصار DDD ( اینجا اوردم چون خیلی با معماری و الگو اشتباه میگیرن)

3. الگوی طراحی نرم افزار (Software Design Pattern):
الگوهای طراحی (Design Patterns)، به شیوه و راه حل های مشکلات رایج در طراحی نرم افزار میپردازند. به عبارت دیگر مجموعه ‌‌ای از بهترین راه‌ حل‌های مشکلات متداول در فرآیند برنامه نویسی نرم ‌افزار را الگوهای طراحی می‌نامند.
الگوهای طراحی جزو معماری‌های نرم افزاری نیستند و فقط شیوه ای صحیح از کدنویسی را ارائه می‌دهند. بنابراین این الگوها فقط در قلمرو کدنویسی ( مخصوصا شی گرا) وارد می‌شوند و مستقل از زبان‌های برنامه نویسی هستند. ( در رابطه با تاریخچه و گروه Gang Of Four معروف به GOF، طبقه بندی کننده و نویسنده اولین کتاب الگوهای طراحی، مطلب جداگانه ای مینویسم)
**هر دیزاین پترن برای اهداف مشخصی ایجاد شده که به برخی از کاربردی ترین ها اشاره میکنم:
1. الگوهای طراحی سازنده(Creational)، به حل مشکلات مربوط به ایجاد اشیا در نرم افزار اشاره میکنند؛ مانند:
- الگوهای سازنده یا Builder، کارخانه یا Factory، یکتا/یگانه یا Singleton،
تزریق وابستگی یا Dependency Injection
2. دسته دیگر معروف به الگوهای طراحی ساختاری(Structural)، به مدیریت ارتباط میان کلاس‌ها و شی‌ها با یکدیگر پرداخته مانند:
- الگوهای فساد یا Facade، مخزن یا Repository، تزئین کننده یا Decorator، آداپتور یا Adapter، پُل یا Bridge، پراکسی یا Proxy
3. دسته دیگری معروف به الگوهای طراحی رفتاری(Behavioral)، به راهکارهای کدنویسی مربوط به تعامل و ارتباط اشیا با یکدیگر میپردازند؛ مانند:
- الگوهای دستور یا Command، واحد کار یا UnitOfWork، واسطه گر یا Mediator، توکن یا Memento

* الگوهای طراحی مزایایی همچون افزایش سرعت توسعه، انعطاف و توسعه پذیری، کاهش خطاها، مشکلات و میزان کدنویسی نرم افزار را به همراه دارند. ( البته کد کمتر همیشه درست یا خوب نیست، کد بیشتر هم همینطور، کد تمیز و ساختار مند انعطاف، مطالعه و توسعه پذیری توسط دیگران رو هم بالا میبره)
در عین حال استفاده نادرست و غلط از آنها نتیجه عکس خواهد داد و میتواند سربار و مشکلات دیگری اضافه کند؛ مانند استفاده های نادرست از الگوهای طراحی ریپازیتوری، تزریق وابستگی و ioc
در ادامه به ترتیب به تشریح 3 مفهوم فوق میپردازم.
@csharpfriends
#SoftwareArchitecture #SoftwareArchitecturePattern #SoftwareDesignPattern

گروه تبادل نظر و پرسش و پاسخ کانال: https://news.1rj.ru/str/csharpfriendsgroup
هر گونه انتقاد، پیشنهاد، مطلب و صحبتی داشتید میتونید با من و بقیه به اشتراک بگذارید، با نام خودتون، ناشناس یا هر شکل دیگه ای. هیچ چیز شخصی نیست و هدف، یادگیری و اشتراک دانش هست. انشالله تحت یک پلتفرم آنلاین در آینده.
اگر دوست داشتید به دیگران هم معرفی کنید.
@csharpfriends

از سری مطالب معماری های نرم افزار #3
در مطلب قبل در رابطه با 3 مفهوم معماری، الگوی معماری و الگوی طراحی در معماری نرم افزار توضیح داده شد. حال به چند نمونه معروف و رایج معماری های نرم افزار (Software Architecture) میپردازیم.

1.1 معماری یکپارچه (Monolithic)
در این معماری همه چیز در یک دید کلی ترسیم و پیاده سازی شده است. یک نرم افزار میتواند شامل ده ها و صد ها بخش (قابلیت/سرویس) باشد؛ که همگی در کنار هم و در یک نرم افزار واحد جای داده شده اند. نرم افزارهای مدیریت محتوا، CRM برخی از مثال های نرم افزار های تجاری یکپارچه اند. این نرم افزار ها قابلیت ها و کارهای زیادی را به صورت واحد انجام میدهند. مثلا ثبت نام و مدیریت کاربران، مدیریت محتوا و دیتابیس، سرویس های ارتباط با مشتریان و پشتیبانی و ...
اینگونه نرم افزار ها معمولا شامل چند بخش میشوند، بانک اطلاعاتی، رابط کاربری و بخش سمت سرور که مدیریت درخواست ها را انجام میدهد و واسطه پردازش داده های بانک اطلاعاتی با رابط کاربری میباشد.

این معماری قدمت زیادی دارد، اگر تجربه کار با سامانه ها و نرم افزار های قدیمی 10 سال پیش رو داشته باشید، بخوبی ساختار و مشکلات نگهداری و توسعه آنها را درک میکنید. هنوز هم بسیاری از سامانه ها و نرم افزار های دولتی و خصوصی بر پایه این معماری و فریم ورک های قدیمی است. دلایل عدم توانایی در ارتقا و توسعه آنها هم کاملا مشخص است. برخی از مزایا و معایب این معماری در زیر آورده شده:
+ مزایا (بیشتر مزایا برای نرم افزار هایی در مقیاس کوچک تا متوسط صادق است) :
* سهولت توسعه و نگهداری در ابتدای کار
* هزینه کم راه اندازی و نگهداری
* دغدغه های کمتر درباره امنیت و محافظت از نرم افزار، به دلیل یکپارچه بودن همه عملیات ها و نظارت بر آنها.
* پرفوورمنس و کارایی بهتر، به دلیل سرعت بالاتر دسترسی به حافظه اشتراکی، نسبت به سرعت پردازش و ارتباطات از طریق شبکه و کانال ها در معماری هایی مثل میکروسرویس.
- معایب:
* مقیاس پذیری و ارتقا: یکی از دشوارترین کارها در این نوع معماری است؛ زیرا همه اجزاء به صورت یک واحد یکتا در کنار هم چیده شده اند و نمیتوان فقط بخش ها و سرویس های خاصی را بیشتر کرد یا ارتقا داد.
* پیچیدگی و عدم انعطاف تکنولوژی ها، توسعه پذیری کم: هر تکنولوژی و کتابخانه ای که در طول توسعه نرم افزار استفاده شده شامل وابستگی ها و بخش های مختلفی هست که توسعه پذیری و انعطاف رو در برابر حذف یا تغییر دادن اونها به شدت کم میکنه. نتیجتا ساختار ها، فریم ورک ها و کتابخانه های استفاده شده در این نرم افزار، به اجبار باید در طول توسعه رعایت شوند؛ درغیر اینصورت کل نرم افزار باید زیر و رو شود (مثلا برای زبان برنامه نویسی یا یک کتابخانه مثل Entity freamework).
* استقرار، عیب یابی و بروزرسانی: در صورتی که بخشی از نرم افزار آپدیت شود و یا به مشکلی در راه اندازی بخورد، کل نرم افزار باید دوباره بروزرسانی و راه اندازی شود.
* پایداری کم، تفکیک پذیری پایین: در صورتی که بخشی از نرم افزار مثلا یک سرویس، منجر به بروز خطا ای در سیستم یا اختلالی در عملکرد نرم افزار شود، ممکن است کل نرم افزار را با مشکل مواجه کند و از کار بیندازد. همچنین پایین بودن امکان تفکیک سطوح مختلف، یا فرضا ماژولی به حافظه بیشتری نیاز داشته باشد و دیگری به پردازنده قوی تری.
* درک سخت تر، به دلیل پیچیدگی و اتصالات سفت بخش های مختلف برنامه در طول روند بزرگ و بزرگ تر شدن آن، به سختی میتوان عملکردی در نرم افزار را پیدا کرد و تغییر داد. علاوه بر آن مطالعه و تحلیل همه کدها به شدت زمان بر خواهد شد.
@csharpfriends
#SoftwareArchitecture #Monolithic

از سری مطالب معماری نرم افزار #4

1.2 معماری سرویس گرا (SOA)
به طور معمول با استفاده از معماری سرویس گرا و یا SOA، یک سیستم نرم افزاری به عنوان ترکیبی از سرویس‌های مختلف، طراحی و ایجاد می شود. مثلا سرویس های پرداخت، محصولات فروشگاه، گزارشگیری،احراز هویت. (نرم افزار به عنوان سرویس)
مشابه معماری یکپارچه، این سرویس ها که همگی جهت پاسخ به نیازها و معمولا در قالب یک نرم افزار طراحی شده اند، به صورت وب سرویس های جداگانه ارائه میشوند. اما از نظر ساختاری همچنان شباهت زیادی به معماری یکپارچه دارند. از اهداف اصلی SOA استفاده مجدد از عملکردهای سیستم و اشتراک گذاری اجزای آن است (برخلاف میکروسرویس ها که مستقل اند و اشتراک گذاری رو به حداقل میرسونن و بیشتر مفهوم bounded-context رو ارائه میدن).
پروتکل اصلی ارتباطی اینگونه نرم افزار ها Soap است. حتما با وب سرویس های قدیمی مثل asmx و wcf ها در دات نت سر و کار داشتید.
محاسبات سرویس گرا (SOC) ، نمونه ای از محاسبات است که در آن طراحی و توسعه سیستم های کاربردی بر پايه سرویس به عنوان عنصر اساسی ، انجام می گیرد. سرویس ها عناصری هستند که مستقل از پلتفرم بوده و در ساخت سیستمهای توزیع شده سریع و ارزان قیمت کمک می نمایند. همچنین سازمانها را قادر می- سازند تا توابع خود را از طریق زبانها و پروتکلهای بر پایه XML پیاده سازی و بر روی اینترنت یا اینترانت ارائه نمایند.
پروتکل های انتقال پیام متعددی میان سرویس ها استفاده میشود( در مطلب دیگری پروتکل ها رو توضیح میدم) که هر کدام شیوه پیاده سازی متفاوتی ارائه میکنند، برخلاف میکروسرویس ها که معمولا بر بستر استاندارد http rest ارتباط دارند و هرگونه کلاینت ای میتواند با آنها بدون وابستگی ارتباط برقرار کند.
در این معماری عملکرد و سرویس ها به 4 دسته تقسیم میشن:
* سرویس های تجاری: شامل سرویس های اصلی که توسط XML نمایش داده میشن.
* سرویس های سازمانی: برای برآورده کردن و پیاده سازی عملکردهایی که در لایه تجاری مورد نیاز هست، به عنوان واسط سرویس های زیر بنایی و برنامه عمل میکنن.
* سرویس های برنامه کاربردی: لایه ای که هر کدام از برنامه های کاربردی (سرویس ها) در آن توسعه داده میشود و توسط رابط کاربری و UI از اونها استفاده میشه.
* سرویس های زیربنایی: عملکرد های عمومی مشترک برنامه که میتونن از طریق بقیه برنامه ها و سرویس ها هم فراخوانی بشن؛ مانند مدیریت و احراز هویت کاربران.

+ مزایا:
* قابلیت تغییر و تحویل سریعتر، به شما اجازه میدهد عملکرد سرویس ها را تغییر داده و سریعتر آنها را به مصرف کننده برسانید.
* افزایش تعامل و امکان استفاده مجدد بیشتر، در سطوح مختلف مانند سرویس ها و داده ها
* تکامل و توسعه تدریجی، امکان افزودن قابلیت ها و بخش های مختلف را در قالب سرویس های جدید آسان تر میکند. بدین صورت دیگر مجبور به طراحی و استقرار کل نرم افزار بصورت یکجا و کلی نیستید.
* انعطاف پذیری بیشتر نسبت به معماری یکپارچه، امری است که باعث میشود سرویس ها چه داخل سازمان ها و چه خارج از آنها، منعطف تر و تغییر پذیر تر باشند.
- معایب:
* مشابه معماری یکپارچه، معمولا اکثر قابلیت ها و سرویس های نرم افزار در یک پروژه و تحت یک نرم افزار واحد به صورت وب سرویس نوشته میشوند که وب سرویس ها و لایه های کاربردی و عملیاتی آنها مشابه Monolithic است.
* زبان ارتباطی xml
* ارتباطات مستقیم وب سرویس ها و پروتکل ارتباطی میان آنها
* پرفورمنس کمتر بدلیل مشکلات مربوط به تاخیر و اختلال در ارتباطات بین سرویس ها، به دلیل ماهیت شبکه و بسترهای ارتباطی که در معماری های مبتنی بر سرویس رایج هستند

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

@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #SOA

از سری مطالب معماری نرم افزار #5

1.3 مقدمه ای بر معماری میکروسرویس (Microservice)
رشد و تکامل در هر چیزی قابل مشاهده و اندازه گیری هست؛ تکامل گونه های جانوران، طبیعت، نسل های مختلف، علم و خیلی چیزهای دیگه پروسه های طولانی و زیادی رو طی کردن تا به شکل امروزی در اومدن و همچنان تا وقتی دنیا دنیاست، هر چیزی یا محکوم به فناست یا تکامل. فلسفیش نمیکنم، مقصودم بیان چرخه تغییر و ایجاد چیزهای مختلف در طول زمانه.
روزگاری در دنیای برنامه نویسی و نرم افزار، معماری های مختلفی معرفی و ابداع میشدن. یک روز معماری P2P، روز دیگری Master Slave، کلاینت-سرور، Mainframe و الی ماشالله، که در دهه های 1960-1970 و تا مدت ها بعد رشد و استفاده زیادی داشتند. نیازمندی ها روز به روز بیشتر و پیچیده تر میشن، برنامه ها بزرگ تر و توسعه و نگهداریشون هم به مراتب سخت تر و هزینه برتر.
حتی تا دهه اخیر، معماری سرویس گرا (SOA) با کلی ویژگی و برتری جزو پرکاربرد ترین معماری در طراحی نرم افزار ها و سامانه ها بود. با توجه به حجم بسیار زیادی از چیزهایی که دهه های پیشین در موردش گفته میشد و یک جورایی سوپرمنی آمده بود تا بسیاری از نیازمندی های سازمان ها و نرم افزار های Enterprise رو حل کنه. انصافا هم در دوره خودش بسیاری کاربرد ها داشت و داره.
امکان ایجاد ارتباط های مستقیم میان نرم افزار ها و اجزای مختلف سازمان و اشتراک گذاری داده میان آنها، از برجسته ترین نقطه قوت SOA هست. اکثر سامانه های دولتی و تجاری عمومی و خصوصی سازمان ها به شیوه سرویس گرا طراحی شدند. سامانه های وزارت دارائی، صنعت و معدن، استانداری ها و تعداد کثیری سرویس که من دیدم و در توسعه برخی از اونها نقش داشتم، هنوز هم بر پایه معماری SOA هستند.
با تکنولوژی وب سرویس های asmx و wcf دات نت و بعد ها web api و REST
فرآیندی که شما درخواست میکنید از طریق وب سرویس های مختلف پردازش و منتقل میشن. از سامانه ای به سامانه دیگر، از وزارت بهداشت به ثبت احوال و به دارائی و ورزش؛ نه فقط در کشور ایران، در بسیاری از کشور های جهان امثال بانک ها هم به همین صورت اند. خیلی هاشون انقدر در هم تنیده و بزرگ شدن که روزانه اخبار هک شدن و درز اطلاعات یا از کار افتادنشون رو میشنویم (در کشور عزیز ما البته همه دیتاهامون کف اینترنت ریخته، به لطف دوستان و اربابان)

در ادامه به شرح علل به وجود اومدن میکروسرویس ها و دلایل استفاده از اونها میپردازم
@csharpfriends
#SoftwareEngineering #SoftwareArchitecture #Microservice

چگونه تصمیم گرفتم از Blazor استفاده کنم:

مدتی هست که در حال نوشتن یک سیستم مدیریت محتوا و وبلاگ بر پایه معماری میکروسرویس هستم که دربارش توضیح مفصلی در مطلب دیگه ای خواهم داد.
رابط کاربری و سمت فرانت اند رو اول با Angular شروع کردم به پیاده سازی. متای سرویس ها و مدل های سمت سرور به صورت خودکار توسط nswag تولید میشه برای کلاینت آنگولار. nswag کتابخانه ای برای تولید کدهای سمت سرور شما برای کلاینت ها با زبان های مختلفی مثل typenoscript, c#, js و ... استفاده میشه.
فقط نیاز هست تا ماژول ها، کامپوننت های مورد نظر و فراخوانی سرویس ها نوشته بشه که در کلاینت generate شده. برای من بخش سخت و طاقت فرسای کار طراحی رابط کاربری و سر و کله زدن با پکیج های node بود. علاوه بر اون syntax تایپ اسکریپت (که باز نسبت به js خیلی بهتره) یه سری قواعد متفاوتی داره. در عین حال فریم ورک خوبیه هم از لحاظ سرعت و هم ابزارها و امکانات زیادی که براش تولید شده. امکان PWA کردن اپ هم به راحتی هست.
اما همونطور که گفتم چند چیز اذیتم میکرد، اول پکیج های بسیار زیاد npm و مدیریت ورژن ها و آپدیت هاشون که کلی side effect و باگ ممکنه ایجاد بکنن در برنامه. دوم با syntax اش خیلی راحت نبودم و کلی باید میگشتم تا مثلا بفهمم داده های دریافتی رو چطوری Map میکنن و کلی تابع و چیز مختلف که داره.
این مشکلات برای امثال من بیشتر پر رنگ هست که فرانت کار حرفه ای نیستن یا با این فریم ورک ها زیاد کار نکردن. برای کسی که کلی وقت گذاشته و پروژه زده مسلما راحت تره کما اینکه میشنوم خیلیاشون به مشکلات آنگولار واقف ان.
در درجه بعد نمیخواستم mvc بزنم فرانت رو چون SPA میخواستم.
تا چند وقت پیش که با یکی از دوستان بحث Blazor و وب اسمبلی شد. از نحوه کارکردش تا مقایسه اش با مابقی فریم ورک ها. مهمتر از همه بحث وب اسمبلی.
بعد از اون مشتاق شدم درباره Blazor در دات نت 5، یه تحقیق مجدد بکنم. دیدم نسبت به ۲ سال پیش خیلی بهتر شده هر چند هنوز جای کار داره اما سریع باهاش ارتباط گرفتم. وب اسمبلی و در کنارش طراحی رابط کاربری با سی شارپ و قابلیت هاش برام جذاب بود. کما اینکه افرادی مثل من که به سی شارپ و net core تسلط بیشتری دارن تا جاوا اسکریپت و تایپ اسکریپت، به راحتی میتونن باهاش فرانت اند رو هم پیاده بکنن و چندین ماه درگیر یادگیری فریم ورک های دیگه و سر و کله زدن باهاشون نشن.
به خصوص که من نیاز دارم تا برای پروژم فرانت هم طبق نیازهای خودم پیاده سازی کنم.
در ادامه درمورد وب اسمبلی و فریم ورک Blazor.net یه توضیحی میدم و نمونه پروژه ای که باهاش پیاده کردم رو در گیتهاب قرار میدم تا بقیه علاقه مندان هم بتونن باهاش آشنا بشن.
@csharpfriends #Blazor #WebAssembly #FrontEnd

اگر اهل موسیقی مخصوصا موزیکای خاص موقع کار کردن هستین میتونین اینجا دانلود کنین و یا با بقیه به اشتراک بزارین.
📣 channel : @PG_sound
group:
https://news.1rj.ru/str/ProgrammingSound