win xp (ره)

cobol

از شاهکارای موسیقی هستن اینا خداییش ( به مولا؟! :)، روحتون رو بعد پاپ و رپ و اتل متل تتل با اینا بشورین. :(مدیونین اگر فکر کنین صدا و سیمای مملکت خودش آهنگاشو نمیسازه و از کفار و بیگانه استفاده میکنه ها :))
میزارم گروه مثل همیشه.
https://news.1rj.ru/str/csharpfriendsgroup/293
این سبک هم گوش کنین عشق کنین.
https://news.1rj.ru/str/csharpfriendsgroup/313
https://news.1rj.ru/str/csharpfriendsgroup/343

سریع و کوچیک، سازگار و منعطف

حتما اسمشو شنیدین، تو کنفرانس ها، مقاله ها، کاربرد هاش در میکروسرویس ها و کلاود. وقتی صحبت از Service میشه وب سرویس و api های soap و rest میاد تو ذهنمون. تو خیلی از استفاده ها web api یا همون restful api design نیاز هامون رو مرتفع میکنه. پروتکل http با قواعد و ساختار استاندارد، راحت و سازگار با همه. مهم نیست چه کلاینتی یا زبانی استفاده میکنین، فقط با ارسال یک http request میتونین با api ها ارتباط بگیرین.
دیگه تشریحش نمیکنم همه http و rest و api رو بلدین و از مزایا و محدودیت هاشم مطلعین. در کنار این گرامی وب سوکت هم هست. پروتکل Http2 هم با امکانات بیشتر قویتر از http1 عه. حالا چی میشه که میریم سمت سوکت؟ مثلا مهمترین کاربرد signalr و signalgo و مشابه هاشون ارتباطات بلادرنگ، دو طرفه و سریعه؛ دارای سربار کمتر نسبت به یک درخواست http معمولی که دارای قاعده خاصیه ( شما لایه نیتیوش رو نمیبینید، چون توسط فریم ورک و کتابخونه انجام میشه، ولی میتونین دربارش تحقیق کنین که چطوری یک http request/response پردازش و ارسال میشه). کار ندارم خلاصه همینقدر گفتم که بارز ترین مفاهیمشون رو داشته باشین.
حالا اگر شما بخواید یک برنامه چت، استریم موسیقی/ویدئو، یا در کل ارتباط real time و همیشه برخط داشته باشین با api نمیتونین کار کنین. چون بر پایه درخواست‌ و پاسخ کار میکنه یعنی باید درخواستی باشه تا پاسخی داده بشه و در انتها همه چیز بسته و فراموش میشه. برعکسش تو سوکت، ارتباط شما با مقصد میتونه همیشه باز بمونه مثل سیم یا لوله همه چی داخلش در رفت و امده)
اگر یکی پیام بفرسته همون لحظه همه میتونن پیام رو دریافت کنن ui شون رو اپدیت کنن یا هر عمل دیگه ای در سمت کلاینت و سرور انجام بدن. در مقابل rest api های مرسوم که باید مثلا هر ده ثانیه هی برن از سرور بپرسن سلام چه خبر پیام جدیدی هس؟! قطعا این روش هزینه زیادی برای هر دو طرف داره، ممکنه تا چندساعت دیگه هم هیچ اتفاقی رخ نده ولی کلاینت ها یکسره باید ریکوئست بزنن. اصلا ممکنه بعد درخواست کلاینت برای چک کردن پیام ها سریع یه پیام جدید ثبت شه ولی کلاینت تا interval مشخص شده بعد هیچی نميدونه! (مثلا ده ثانیه یا چند دقیقه بعد که دوباره درخواست چک کردن بفرسته به سرور)
خلاصه این روش‌ خیلی ضایعه، منابع و یکپارچگی داده تو همچین سیستمی از دست میره.

یه فرآیند رو مثال میزنم، مثلا شما زنگ میزنی سامانه نوبت دهی یا پشتیبانی x، میگه وایستا تو صف تا نوبتت شه، یا میگه هنوز جواب درخواستتون نیومده. حالا، یا باید تا صبح هی زنگ بزنی بگی سلام چی شد؟ اومد؟ نیومد و ..، یا بهت بگن هر موقع نوبتتون شد یا جوابی اومد بهتون اطلاع میدیم( مثلا تماس یا پیام میفرستیم). قطعا سیستم دومی بهتره نه؟ میری سراغ زندگیت تا اونا وظیفشونو انجام بدن.
همین سیستم رو ببرید سمت برنامه نویسی، کلاینت ها به شما وصل میشن و متصل میمونن تا هر وقت بخوان. میتونن باهاتون صحبت کنن هر دفعه هم نیاز نیست از اول خودشونو معرفی کنن. ضمن اینکه هر موقع باهاشون کاری داشته باشید این شما هستین که بهشون اطلاع میدین، دقیقا مثال بالا. فلانی درخواستی داده هر موقع این درخواست تغییر وضعیت پیدا کرد یا نتیجه ای بود شما بهش اطلاع میدین دیگه لازم نیست خودش هی بپرسه، فقط کافیه گوش به زنگ باشه. شبیه سیستم messaging اگر اشنا باشین.
همه اینا رو با داستان سرایی گفتم که برسم به دست پرورده گوگل، حضرت GRPC یا جی آر پی سی. اینجا شما بهتره از یه سیستم بلادرنگ استفاده کنین، پس معمولا میرن سراغ signalr و grpc؛ یا سوکت نویسی native که خیلی سخته و زیاد عاقلانه نیست مجدد اختراع شه وقتی اینهمه کتابخونه خوب هست. بحث پیام رسانی بین سرور ها و کلاینت ها میتونه json باشه، binary باشه، text باشه و ...
یعنی دیتاها به چه فرمتی رد و بدل بشن، خوب json و text خوانا تر و ساده تره برای انسان ولی اینجا بحث ماشین به ماشین بیشتر مهمه. انقدر مهمه که اومدن سریالایزر باینری نوشتن تا دیتا خیلی کوچیک و کم حجم بشه که طبعا سرعت و پرفورمنس کلی سیستم رو به نسبت json چند برابر بیشتر میکنه. به هر حال یک چیزی این دیتا رو موقع ارسال و دریافت باید تبدیل کنه حالا json یا binary. هم signalr و هم grpc سریالایزر های مختلفی دارن پراستفادشون باینریه.
منتها چند تفاوت مهم بین grpc با مثلا signalr هست، اولیش کامپایلره. grpc از protobuf استفاده میکنه یه سری فایل هستن که به عنوان قرارداد شناخته میشن. متد ها و مدل ها و فیلد ها همه میشن قرارداد های سرور و کلاینت. سینتکس زبان خودشم داره یعنی تو c# اگر مینویسیم list اونجا اسمش میشه repeater. یا dictionary میشه map. نوع داده خودشه که کامپایلر میتونه کدهاشو برای بقیه generate کنه.
تو این پست سعی کردم به زبون خودمونی توضیح مقدماتی ای بدم، تو یه پست دیگه فنی تر میشیم.

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

آدام_گرانت
از کتاب" دوباره فکر کن"
__
@TheCourageToChange

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

سیستم احراز هویت و مدیریت کاربری مینویسید؟ jwt بیس و حاوی نقش و دسترسی های پویا و سرویس های کاستوم؟ خب دست خوش به خودتون مربوطه، لابد در امنیت سر رشته کافی دارین و owasp و top 10 رو کامل پیاده کردین و مطلعین، ضمن اینکه با مصائب روز سیستم های احراز هویت و کلاینت های مختلف اشنایید.
ولی اگر نکردین و نمیدونین و فکر کردین با چهارتا جدول user و role و این چیزا الان ایدنتیتی مایکروسافت رو فیتیله پیچ کردین باید بگم چند وقت دیگه با صورتی برافروخته و چشمانی قرمز ( اون قرمز نه، شایدم اره بالاخره فشاره دیگه) میاین میگین سیستم داینامیک پرمیشن و multi device و امنیت و شصت تا فیچر و principle دیگه رو چطوری پیاده کنم که هم یک ترابایت کد و کوئری ننویسم هم استاندارد ها و پروتکل های امنیتی رو رعایت کنم پرفورمنس هم ساییده نشه، که پس فردا از روزنه هاش رو نمایی بکنن حیثیتمون به گاراج بره. شاید بعضیا فکر کنن یه کوکی و jwt میدل ویر و چارتا جدول و سرویسه دیگه این شامبورتی بازیا چیه در میاری مخی بگی بلدی؟! نه اتفاقا به جدم نیستم در حدم که ممبر شیپ و auth سرور بنویسم و چهار روز دیگه مشتری رو به چوخ بدم بعدم فکر کنم، ها دیدی سخت نبود تازه طراحی اختصاصی بود پول بیشتریم گرفتم همینو میکنم تو استین بعدیا( ولی حالا مثلا میشه بگی owasp top10 چیه؟ @_@).
عین مرد میرم از ساختار و دکون دستگاه دو پروژه Identity و Identity server استفاده میکنم و بسته به نیاز روی پروتکل oauth2 و openid connect کاستومایز انجام میدم رو هر چیزی که بخوام، چون میدونم چطوری کار میکنن چی به چیه و نیاز های اینده رو چه سولوشن هایی براش دارم. ولی تکرار مکررات و واضحات نمیکنم، متن بازم که هستن.

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

خودمون انتخاب کردیم که این باشیم😔. گوشه ایش رو در ترند ها میتونین برین ببینین.

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

وب سایت Medium سرشار از مقاله و آموزش های خوبه
https://medium.com/javarevisited/7-best-online-courses-to-learn-asp-net-core-and-mvc-in-depth-a68c1b728090

https://dotnettutorials.net/course/asp-net-core-tutorials/

اموزش ها و تجربیات کاربردی مشفق همدانی گرامی
https://codewithmosh.com/
https://programmingwithmosh.com/

بلاگ murugan mukesh پر از اموزش های خوبه
https://codewithmukesh.com/

https://www.dotnetcurry.com/tutorials/aspnet-core

https://dotnetcoretutorials.com/

https://www.tutorialsteacher.com/

https://www.tutorialspoint.com/asp.net_core/index.htm

https://dotnettips.wordpress.com/
https://dotnetcodetips.com/
https://dailydotnettips.com/

وبسایت بسیار خوب پارسی زبان دات نت tips که پر از تجربیات و منابع مفید تو هر لول ای که هستید هست و نویسندگان خوبی همچون استاد وحید نصیری داره که به جرعت کلی چیزی ازش یاد گرفتم
https://www.dntips.ir/

دولوپر بلاگ برنامه نویسان مایکروسافت هم منابع خیلی خوبی داره مخصوصا برای سطوح بالاتر، که کانال های اموزشیش هم در لینکدین و tv مایکروسافت مثل channel 9 برای معرفی ها و اموزش های حرفه ای ها خیلی معروفه
https://devblogs.microsoft.com/dotnet/
https://docs.microsoft.com/en-us/shows/on-net

وبسایت اسکات هانسلمن
https://www.hanselman.com/blog/
https://dotnet.microsoft.com/en-us/learn/videos

https://www.codecademy.com/

https://www.dotnettricks.com/learn/aspnetcore

از بهترين مجموعه آموزش های کاربردی بلیزور، از اموزش اولیه گرفته تا پیاده سازی spa و pwa اپلیکیشن های واقعی و اکثر چالش ها و نیازمندی های موجود
#Blazor #web_assembly
https://code-maze.com/blazor-webassembly-series/

پلتفرم های آموزشی ویدئویی که بیشتر پولی هستن ولی اکثرشون انقدر پر بازدید هستن که با سرچ کردن اسم اموزش توی اینترنت و کانال های ایرانی خودمون( مثل کانال code for food که قبلا گفتم) هم پیداشون میکنین، اونقدری که یسری از اساتید ترجمه میکنن و برای خودشون میفروشن.
https://www.packtpub.com/

https://www.oreilly.com/

https://www.udemy.com/

https://www.pluralsight.com/paths/aspnet-core

این لیست به مرور آپدیت خواهد شد.
#csharp #aspcore #learning #dotnet

انصافا مجموعه خوب و کاربردی ایه برای یادگیری و استفاده از blazor علل خصوص مدل وب اسمبلی که معمولا با بک اند و سرور ساید ارتباطات خیلی زیادی داره (مگر اپ شما کلا wasm باشه هیج سرور و api ای نداشته باشه همه چیز تو خودش پیاده میشه مثل وصل شدن به دیتابیس و احراز هویت و ..، همه جا هم قابل اجراست اصلا هاستم نمیخواد ولی معمولا کسی نمیخواد همه بیزنس لاجیک و امنیت برنامه رو بفرسته سمت کلاینت)، در کنار بحث خوده blazor اموزش های خیلی خوبه نوشته که چطور احراز هویت کنیم، دسترسی و خطاهارو هندل کنیم، با سرور ارتباط بگیریم، crud کنیم، با استفاده از قدرت c# و پکیج ها، نیاز به js و کتابخونه هاش رو خییلی کم کنیم و ...

https://code-maze.com/blazor-webassembly-series/

عموما فرانت ها از http rest api ها استفاده میکنن چون پروتکل استاندارد و مرسومیه در همه چیز. تو موارد حرفه ای یا خاص تر خب signalr و grpc هم زیاد استفاده میشه، مخصوصا اگر بحث realtime و سرعت مطرح باشه مثل چت، استریم، بازی و ..
که بازم میگم هر چیزی به جاش خیلیم خوبه. هر کی گفت سوکت مطلقا برای فرانت بده مهمل گفته ( کانکشن خیلی زیاد به پروژه یکپارچه تک سروری مهمترین دلیلشه که راهش توزیع کردن و سرویس لود بالانس هست برای سیستمی که خیلی یوزر داره، وگرنه کلاینت از خداشم هست همه چیز براش تولید شه و فقط متد صدا بزنه و کمتر درگیر api بشه). جاش هست آشم هست امکانش برای همه طراحی شده و استفاده میشه.
البته از Http2/3 هم غافل نشید ولی خب بحث چیز دیگه ای بود در گنجایش این پست و اندک دانش و تجربه این حقیر.
#Blazor #WebAssembly #aspcore
@csharpfriends

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

خیلی وقتا میشنویم میگن معماری MVC و MVVM و DDD و Cqrs.. کلا هر چی پترن و رویکرده رو میریزن تو معماری. درباره همه اینا قبلا مفصل نوشتم:
معماری، معماری طراحی، الگوی طراحی.
صرفا چندتا مفهوم غلط اندازه مرسوم رو میگم بازم:

معماری های: سرویس گرا، مبتنی بر سرویس و مایکروسرویس، معماری مونولیت یا همون یکپارچه، MainFrame و ..

معماری های طراحی: MVC, MVVM, MVP
الگوی های طراحی: UnitOfWork، الگوی تزریق وابستگی، الگوی استراتژی، الگوی سینگلتون، الگوی ریپازیتوری، الگوی request reaponse،
* الگوی طراحی معماری (گاها به عنوان رویکرد طراحی هم شناخته میشه) کامند کوئری CQRS (اشاره داره به جدا کردن store و مسئولیت مدل دستورات یا کامندها از کوئری ها ) و event sourcing pattern

متدلوژی و رویکرد ها / تفکر ها مثل،
توسعه دامین محور DDD (طراحی برپایه بیزنس دامین های نرم افزار)،
توسعه تست محور TDD (توسعه بر پایه تست های واحد از پیش نوشته شده، برعکس توسعه معمول که اول پیاده سازی انفاق میفته بعد تست های نفس گیر)،
رویداد محور EDD ( event driven )،
رویکرد پر استفاده رفتار محور BDD ( بزن در رو حالا خدا بزرگه ببینیم چی میشه محور)، رویکرد CDD کپی محور، فحش محور FDD (سازمان ِغذا و دارو امریکا) و ...

یادتون باشه که مثلا شما مجبور نیستید طراحی CQRS پیاده کنید، میتونید همونا رو در یک سرویس بنویسید و همه عملیات crud رو داخل خودش پیاده کنید، اما اگر نیاز دارید به:
- افزایش خوانایی، تفکیک وظایف مدل ها و حذف وابستگی های اضافی.
- جدا کردن عملیات هایی که تغییری در وضعیت و داده های سیستم میدن و خروجی ندارن
- جدا کردن عملیات هایی که تغییری نمیدن و صرفا کوئری های read هستن و خروجی میدن
- صدور دنباله ای از event ها، که بقیه سرویس ها رو از تغییری مطلع میکنن یا میگن بعدش کار دیگه ای رو انجام بده (داخل سیستم یا سرویس های خارجی). مثلا اپدیت کردن کش، دیتابیس read، اپدیت رکورد تو سرویس دیگه ای، زمان بندی انجام کاری در پشت صحنه و صف پیام
- جدا کردن storage داده ها، مثلا جدا کردن دیتابیس read از write برای افزایش پرفورمنس، مقیاس پذیری و parallelism و امنیت
- نگهداری تاریخچه تغییرات دیتا ها و رویداد های نرم افزار به منظور، لاگینگ، گزارش گیری، بازگردانی و رهگیری اتفاقات.
بهترین معماری و الگوی طراحی ای که پیدا میکنید همین CQRS و Event Sourcing عه که به وفور در میکروسرویس ها، سیستم های مقیاس پذیر، سرویس هایی با کوئری های بزرگ و پیچیده استفاده میشه.
به همین خاطر اگر دیدید یک سرویس داره روز به روز بزرگتر و پیچیده تر میشه، وابستگی های زیادی رو تزریق میکنه که لازم نیست بخاطر صدا زدن یک تابع کوچیک استفاده بشن، بهتره معماری رو یک بازنگری بکنید و مسئولیت های سرویستون رو به کامند و کوئری های مستقل بشکنید.
ولی اگر یکی دوتا کلاس سرویس و ریپازیتوری کوچیک دارید که نهایت شیش هفت تا متد و عملیات داره و روز به روز بزرگتر نمیشه و لازم نیست دیتابیس خوندن رو از نوشتن تفکیک کنید، cqrs بیشتر کارتون رو پیچیده و توسعه تون رو زمان بر میکنه. ضمن اینکه برنامه نویس های کمی هستن که واقعا درک و تجربه ای ازش داشته باشن تا سر از کد ها و ساختار در بیارن.
#Architecture #DesignPattern #ArchitecturalPattern #Approach
@csharpfriends

چقدر و در چه وب اپ هایی از blazor استفاده میشه، از دید افزونه wappalyzer:
https://www.wappalyzer.com/technologies/web-frameworks/blazor

awesome blazor resources:
https://project-awesome.org/AdrienTorris/awesome-blazor

#blazor #wasm #webassembly #dotnet

سلام.
امیدوارم سال 1401 سال بهتری برای همتون باشه. سالی سرشار از برکت و موفقیت داشته باشید و ثمره تلاش هاتون، شب بیداری هاتون و صبح زود بیدار شدناتون رو زودتر ببینین و صدای موفقیت همه بلند باشه.
اگر زمانی دلی از کسی شکستم همینجا ازتون طلب بخشش دارم و امیدوارم دل هاتون شاد تر باشه و شرایط زندگی بهتر و بهتر تر.
ارادت مند همگیتون هستم ❤️
کوچیک شما سعید رضایی.
اخرین روز سال 1400، 2022/03/20

#EfCore #BestPractices
Querying Basics:

https://docs.microsoft.com/en-us/ef/core/performance/efficient-querying

https://levelup.gitconnected.com/3-ways-to-improve-the-ef-core-performance-in-your-net-core-app-d9b6295188cc