Forwarded from C & micro & fpga (فرهاد ناصری زاده)
Forwarded from IRCF | اینترنت آزاد برای همه
نسخه ۲.۲۵ از برنامه #oblivionDesktop با تمرکز بر روی بهبود اتصال از طریق حالت Tun، بهینهسازی و کاهش مصرف منابع سختافزار، رفع مشکلات گزارششده و اضافهکردن ۳ زبان جدید (از فهرست کشورهای صدرنشین اعمال #فیلترینگ)، در دسترس قرار گرفت.
🚀 github.com/bepass-org/oblivion-desktop/releases
🛟 github.com/bepass-org/oblivion-desktop/issues
🔍 ircf.space/software
@ircfspace
🚀 github.com/bepass-org/oblivion-desktop/releases
🛟 github.com/bepass-org/oblivion-desktop/issues
🔍 ircf.space/software
@ircfspace
🔥1
Forwarded from DevTwitter | توییت برنامه نویسی
معرفی پکیج Laravel OTP Manager در وب سایت Laravel News
https://laravel-news.com/one-time-password-manager-for-laravel
@DevTwitter | <Saleh Hashemi/>
https://laravel-news.com/one-time-password-manager-for-laravel
@DevTwitter | <Saleh Hashemi/>
Forwarded from Anophel | آنوفل
یه راه خفن برای کنترل این داستان استفاده از چیزی به اسم Semaphore هست. اینجوری میتونی تعداد گوروتینهای در حال اجرا رو محدود کنی.
1. یه کانال با ظرفیت مشخص (N) درست میکنی که این ظرفیت میشه تعداد گوروتینهای همزمانی که میخوای اجرا بشه.
2. کانال رو با N تا "توکن" (هرچیزی مثل عدد) پر میکنی.
3. هر گوروتین قبل از اجرا باید یه توکن از کانال بگیره و وقتی کارش تموم شد، توکن رو برمیگردونه.
4. اگه توکن نباشه، گوروتین منتظر میمونه تا یکی آزاد بشه.
کد داخل تصویر یه مثال ساده با N=2 هست.
#Golang #go #گو #گولنگ
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevTwitter | توییت برنامه نویسی
مفهوم Race Condition رو تا حالا شنیدی؟!
در واقع به درخواستهای همزمانی که روی یه اندپوینت مشخص یا یه داده خاص در سیستم ما اتفاق میفته، Race Condition میگن.
این اتفاق معمولاً زمانی رخ میده که چندین درخواست همزمان بخوان روی یک داده مشترک اثر بذارن یا تغییراتی ایجاد کنن، و اگه به درستی مدیریت نشه، میتونه منجر به باگهای جدی و رفتار غیرمنتظره در سیستم بشه.
چطور Race Condition رو مدیریت کنیم؟
برای رفع این مشکل، من درخواستهای همزمان رو به دو بخش کلی تقسیم کردم:
۱. همزمانی در لایه اپلیکیشن:
این نوع همزمانی زمانی رخ میده که چندین درخواست همزمان به یک منبع یا عملیات خاص در اپلیکیشن دسترسی پیدا کنن.
راهحل پیشنهادی:
از Cache::lock استفاده میکنیم. این روش برای ایجاد یک قفل موقت روی منابع مشترک کاربرد داره.
مثلاً با استفاده از Redis میتونیم مطمئن بشیم که فقط یک درخواست در یک زمان خاص اجازه دسترسی داره.
۲. همزمانی روی دیتابیس:
اینجا از قفلهای دیتابیس استفاده میکنیم تا درخواستهای همزمان رو کنترل کنیم:
FOR SHARE:
این نوع قفل وقتی استفاده میشه که فقط میخوایم داده رو بخونیم، ولی مطمئن بشیم کسی در همون لحظه نمیتونه اون رو تغییر بده.
این قفل اجازه میده درخواستهای دیگه فقط بخونن ولی هیچ عملیات نوشتن یا دستکاری نمیتونه انجام بشه.
FOR UPDATE:
این قفل وقتی استفاده میشه که میخوایم داده رو بخونیم و تغییر بدیم.
وقتی این قفل فعال بشه، هیچ درخواست دیگهای نمیتونه داده رو حتی بخونه یا تغییر بده تا وقتی که تراکنش فعلی کامل بشه.
با این روشهایی که گفتم، میتونیم از درخواستهای همزمان که باعث ایجاد باگ تو پروژمون میشن جلوگیری کنیم.
یادگیری این مفاهیم نهتنها توی پروژههای واقعی خیلی بهدرد میخوره، بلکه میتونه یه سؤال کلیدی توی مصاحبههای شغلی باشه!
@DevTwitter | <Saber Qadimi/>
در واقع به درخواستهای همزمانی که روی یه اندپوینت مشخص یا یه داده خاص در سیستم ما اتفاق میفته، Race Condition میگن.
این اتفاق معمولاً زمانی رخ میده که چندین درخواست همزمان بخوان روی یک داده مشترک اثر بذارن یا تغییراتی ایجاد کنن، و اگه به درستی مدیریت نشه، میتونه منجر به باگهای جدی و رفتار غیرمنتظره در سیستم بشه.
چطور Race Condition رو مدیریت کنیم؟
برای رفع این مشکل، من درخواستهای همزمان رو به دو بخش کلی تقسیم کردم:
۱. همزمانی در لایه اپلیکیشن:
این نوع همزمانی زمانی رخ میده که چندین درخواست همزمان به یک منبع یا عملیات خاص در اپلیکیشن دسترسی پیدا کنن.
راهحل پیشنهادی:
از Cache::lock استفاده میکنیم. این روش برای ایجاد یک قفل موقت روی منابع مشترک کاربرد داره.
مثلاً با استفاده از Redis میتونیم مطمئن بشیم که فقط یک درخواست در یک زمان خاص اجازه دسترسی داره.
۲. همزمانی روی دیتابیس:
اینجا از قفلهای دیتابیس استفاده میکنیم تا درخواستهای همزمان رو کنترل کنیم:
FOR SHARE:
این نوع قفل وقتی استفاده میشه که فقط میخوایم داده رو بخونیم، ولی مطمئن بشیم کسی در همون لحظه نمیتونه اون رو تغییر بده.
این قفل اجازه میده درخواستهای دیگه فقط بخونن ولی هیچ عملیات نوشتن یا دستکاری نمیتونه انجام بشه.
FOR UPDATE:
این قفل وقتی استفاده میشه که میخوایم داده رو بخونیم و تغییر بدیم.
وقتی این قفل فعال بشه، هیچ درخواست دیگهای نمیتونه داده رو حتی بخونه یا تغییر بده تا وقتی که تراکنش فعلی کامل بشه.
با این روشهایی که گفتم، میتونیم از درخواستهای همزمان که باعث ایجاد باگ تو پروژمون میشن جلوگیری کنیم.
یادگیری این مفاهیم نهتنها توی پروژههای واقعی خیلی بهدرد میخوره، بلکه میتونه یه سؤال کلیدی توی مصاحبههای شغلی باشه!
@DevTwitter | <Saber Qadimi/>
Forwarded from DevTwitter | توییت برنامه نویسی
کاربری به اسم frosty این سوالات رو تو Stack Overflow پرسیده و FBI هم از طریق این اسمش و کدهایی که تو سایتش استفاده کرده تونسته ردشو بزنه.
فریمورکی که هم که استفاده کرده CodeIgniter پیاچپی بوده. یه نفر بهش میگه که چتاشون لو رفته و باید سریع پاکش کنه که اومده سرچ کرده چطوری session رو تو CodeIgniter پاکش کنه.
پ.ن: این کاربر راس ویلیام اولبریکت، بنیانگذار سایت خرید و فروش مواد مخ.در در دارک وب به نام Silk Road بود که در اکتبر ۲۰۱۳ تحت عملیاتی مشترک از سوی افبیآی، اداره مبارزه با مواد مخدر، وزارت دادگستری و آژانس امنیت ملی دستگیر و به حبس ابد محکوم شد.
پ.ن۲: اگه خواستین جرمی مرتکب بشین، جوابای Stack Overflow رو مستقیم کپی نکنید، خودتون بنویسید
پادکست جذاب Silk Road از چنلبی رو حتما گوش کنید فوقالعاده هس.
@DevTwitter | <Reza Asgharzadeh />
فریمورکی که هم که استفاده کرده CodeIgniter پیاچپی بوده. یه نفر بهش میگه که چتاشون لو رفته و باید سریع پاکش کنه که اومده سرچ کرده چطوری session رو تو CodeIgniter پاکش کنه.
پ.ن: این کاربر راس ویلیام اولبریکت، بنیانگذار سایت خرید و فروش مواد مخ.در در دارک وب به نام Silk Road بود که در اکتبر ۲۰۱۳ تحت عملیاتی مشترک از سوی افبیآی، اداره مبارزه با مواد مخدر، وزارت دادگستری و آژانس امنیت ملی دستگیر و به حبس ابد محکوم شد.
پ.ن۲: اگه خواستین جرمی مرتکب بشین، جوابای Stack Overflow رو مستقیم کپی نکنید، خودتون بنویسید
پادکست جذاب Silk Road از چنلبی رو حتما گوش کنید فوقالعاده هس.
@DevTwitter | <Reza Asgharzadeh />
Forwarded from Software Engineer Labdon
📣 هش SHA 256 چگونه کار میکند؟
این وبسایت قدم به قدم فرآیند هش کردن رشته با الگوریتم Sha256 را بصورت گرافیکی نشان میدهد:
🔗 https://sha256algorithm.com/
🔹🔹🔹🔹🔹
➖➖➖➖➖➖➖➖
https://news.1rj.ru/str/addlist/KpzXaiSpKENkMGM0
این وبسایت قدم به قدم فرآیند هش کردن رشته با الگوریتم Sha256 را بصورت گرافیکی نشان میدهد:
🔗 https://sha256algorithm.com/
🔹🔹🔹🔹🔹
➖➖➖➖➖➖➖➖
https://news.1rj.ru/str/addlist/KpzXaiSpKENkMGM0
Forwarded from Syntax | سینتکس (Daimon)
6 الگوی برتر معماری نرمافزار
معماری مونولیتیک (Monolithic Architecture)
در معماری مونولیتیک، تمام اجزای یک برنامه در یک کدبیس واحد و یکپارچه ترکیب میشوند. این رویکرد، فرآیند استقرار (Deployment) را ساده کرده و برای برنامههای کوچک مدیریت آن آسانتر است. با این حال، با رشد برنامه، این معماری میتواند سنگین و پیچیده شود، به طوری که مقیاسپذیری و نگهداری آن دشوار میگردد. هر تغییری در بخشی از برنامه ممکن است نیازمند استقرار دوباره کل سیستم باشد.
این معماری برای پروژههای کوچک و تیمهای کوچک مناسب است، اما برای پروژههای بزرگتر، به دلیل وابستگیهای زیاد میان اجزاء، مدیریت تغییرات بسیار دشوار میشود.
الگوی (Controller-Worker Pattern)
این الگو منطق کنترل (Control Logic) را از منطق پردازش (Processing Logic) جدا میکند. کنترلر وظیفه مدیریت درخواستهای ورودی، جریان دادهها و تخصیص وظایف به اجزای کارگر (Worker) را بر عهده دارد. اجزای کارگر وظایف پردازشی واقعی را انجام میدهند. این الگو برای مدیریت وظایف غیرهمزمان (Asynchronous Tasks) مفید است و میتواند مقیاسپذیری را با امکان اجرای همزمان چندین نمونه از اجزای کارگر بهبود بخشد.
مناسب برای سیستمهایی است که بار پردازشی غیرهمزمان دارند، مانند پردازش صفها (Queues) یا مدیریت درخواستهای سنگین.
معماری میکروسرویسها (Microservices Architecture)
معماری میکروسرویسها برنامه را به سرویسهای کوچک و مستقل تقسیم میکند که از طریق APIهای مشخص با یکدیگر ارتباط برقرار میکنند. هر سرویس مسئول یک قابلیت خاص از کسبوکار است و میتواند بهطور مستقل توسعه، استقرار و مقیاسپذیری شود. این معماری انعطافپذیری بیشتری فراهم میکند و امکان استفاده از فناوریهای مختلف برای سرویسهای مختلف را میدهد. اما مدیریت سرویسها و ارتباط بین آنها میتواند پیچیدگیهایی به همراه داشته باشد.
این معماری مناسب سازمانهایی است که نیاز به توسعه سریع و مقیاسپذیری خدمات دارند. اما نیازمند ابزارهای مناسب برای نظارت، هماهنگی و مدیریت ارتباطات میان سرویسها است.
مدل (Model-View-Controller یا MVC)
الگوی MVC یک برنامه را به سه بخش مرتبط تقسیم میکند:
- مدل (Model): وظیفه مدیریت دادهها و منطق کسبوکار را دارد.
- نما (View): دادهها را به کاربر نمایش میدهد.
- کنترلر (Controller): ورودی کاربر را مدیریت کرده و با مدل تعامل دارد.
این جداسازی باعث سازماندهی بهتر کد میشود و مدیریت و مقیاسپذیری برنامه، بهویژه در توسعه وب، را آسانتر میکند.
این الگو در اکثر فریمورکهای وب مانند Django و Ruby on Rails استفاده میشود و برای پروژههایی که نیاز به تعامل زیاد با کاربر دارند، ایدهآل است.
معماری رویداد-محور (Event-Driven Architecture)
در معماری رویداد-محور، اجزا از طریق تولید و مصرف رویدادها با یکدیگر ارتباط برقرار میکنند. هنگامی که یک رویداد رخ میدهد (مانند یک اقدام کاربر یا تغییری در سیستم)، رویداد های خاصی در سیستم ایجاد میشود و دیگر اجزای سیستم نسبت به رویداد ها اکشن مناسبی که نیاز دارند را انجام می دهند. این معماری بسیار جدا از هم (Decoupled) است و مقیاسپذیری و انعطافپذیری بیشتری فراهم میکند، چرا که اجزا میتوانند بهطور مستقل تکامل یابند.
این معماری در سیستمهای توزیعشده بسیار مفید است.
معماری لایهای (Layered Architecture)
در معماری لایهای، برنامه به لایههای مجزا با وظایف مشخص تقسیم میشود. لایههای رایج شامل موارد زیر هستند:
- لایه ارائه (Presentation Layer): وظیفه نمایش داده به کاربر.
- لایه منطق کسبوکار (Business Logic Layer): مدیریت منطق اصلی برنامه.
- لایه دسترسی به داده (Data Access Layer): مدیریت تعامل با پایگاه داده.
هر لایه تنها با لایه مجاور خود ارتباط برقرار میکند که باعث جداسازی وظایف (Separation of Concerns) میشود. این الگو نگهداری را آسان کرده و به تیمها اجازه میدهد بهطور مستقل روی لایههای مختلف کار کنند. با این حال، وجود لایههای متعدد ممکن است باعث کاهش عملکرد به دلیل سربار ناشی از ارتباط میان لایهها شود.
این معماری برای سیستمهای بزرگ و تیمهای توسعه که به تفکیک وظایف نیاز دارند، مناسب است. اما باید بهینهسازی لازم برای جلوگیری از کاهش عملکرد انجام شود.
source
@Syntax_fa
معماری مونولیتیک (Monolithic Architecture)
در معماری مونولیتیک، تمام اجزای یک برنامه در یک کدبیس واحد و یکپارچه ترکیب میشوند. این رویکرد، فرآیند استقرار (Deployment) را ساده کرده و برای برنامههای کوچک مدیریت آن آسانتر است. با این حال، با رشد برنامه، این معماری میتواند سنگین و پیچیده شود، به طوری که مقیاسپذیری و نگهداری آن دشوار میگردد. هر تغییری در بخشی از برنامه ممکن است نیازمند استقرار دوباره کل سیستم باشد.
این معماری برای پروژههای کوچک و تیمهای کوچک مناسب است، اما برای پروژههای بزرگتر، به دلیل وابستگیهای زیاد میان اجزاء، مدیریت تغییرات بسیار دشوار میشود.
الگوی (Controller-Worker Pattern)
این الگو منطق کنترل (Control Logic) را از منطق پردازش (Processing Logic) جدا میکند. کنترلر وظیفه مدیریت درخواستهای ورودی، جریان دادهها و تخصیص وظایف به اجزای کارگر (Worker) را بر عهده دارد. اجزای کارگر وظایف پردازشی واقعی را انجام میدهند. این الگو برای مدیریت وظایف غیرهمزمان (Asynchronous Tasks) مفید است و میتواند مقیاسپذیری را با امکان اجرای همزمان چندین نمونه از اجزای کارگر بهبود بخشد.
مناسب برای سیستمهایی است که بار پردازشی غیرهمزمان دارند، مانند پردازش صفها (Queues) یا مدیریت درخواستهای سنگین.
معماری میکروسرویسها (Microservices Architecture)
معماری میکروسرویسها برنامه را به سرویسهای کوچک و مستقل تقسیم میکند که از طریق APIهای مشخص با یکدیگر ارتباط برقرار میکنند. هر سرویس مسئول یک قابلیت خاص از کسبوکار است و میتواند بهطور مستقل توسعه، استقرار و مقیاسپذیری شود. این معماری انعطافپذیری بیشتری فراهم میکند و امکان استفاده از فناوریهای مختلف برای سرویسهای مختلف را میدهد. اما مدیریت سرویسها و ارتباط بین آنها میتواند پیچیدگیهایی به همراه داشته باشد.
این معماری مناسب سازمانهایی است که نیاز به توسعه سریع و مقیاسپذیری خدمات دارند. اما نیازمند ابزارهای مناسب برای نظارت، هماهنگی و مدیریت ارتباطات میان سرویسها است.
مدل (Model-View-Controller یا MVC)
الگوی MVC یک برنامه را به سه بخش مرتبط تقسیم میکند:
- مدل (Model): وظیفه مدیریت دادهها و منطق کسبوکار را دارد.
- نما (View): دادهها را به کاربر نمایش میدهد.
- کنترلر (Controller): ورودی کاربر را مدیریت کرده و با مدل تعامل دارد.
این جداسازی باعث سازماندهی بهتر کد میشود و مدیریت و مقیاسپذیری برنامه، بهویژه در توسعه وب، را آسانتر میکند.
این الگو در اکثر فریمورکهای وب مانند Django و Ruby on Rails استفاده میشود و برای پروژههایی که نیاز به تعامل زیاد با کاربر دارند، ایدهآل است.
معماری رویداد-محور (Event-Driven Architecture)
در معماری رویداد-محور، اجزا از طریق تولید و مصرف رویدادها با یکدیگر ارتباط برقرار میکنند. هنگامی که یک رویداد رخ میدهد (مانند یک اقدام کاربر یا تغییری در سیستم)، رویداد های خاصی در سیستم ایجاد میشود و دیگر اجزای سیستم نسبت به رویداد ها اکشن مناسبی که نیاز دارند را انجام می دهند. این معماری بسیار جدا از هم (Decoupled) است و مقیاسپذیری و انعطافپذیری بیشتری فراهم میکند، چرا که اجزا میتوانند بهطور مستقل تکامل یابند.
این معماری در سیستمهای توزیعشده بسیار مفید است.
معماری لایهای (Layered Architecture)
در معماری لایهای، برنامه به لایههای مجزا با وظایف مشخص تقسیم میشود. لایههای رایج شامل موارد زیر هستند:
- لایه ارائه (Presentation Layer): وظیفه نمایش داده به کاربر.
- لایه منطق کسبوکار (Business Logic Layer): مدیریت منطق اصلی برنامه.
- لایه دسترسی به داده (Data Access Layer): مدیریت تعامل با پایگاه داده.
هر لایه تنها با لایه مجاور خود ارتباط برقرار میکند که باعث جداسازی وظایف (Separation of Concerns) میشود. این الگو نگهداری را آسان کرده و به تیمها اجازه میدهد بهطور مستقل روی لایههای مختلف کار کنند. با این حال، وجود لایههای متعدد ممکن است باعث کاهش عملکرد به دلیل سربار ناشی از ارتباط میان لایهها شود.
این معماری برای سیستمهای بزرگ و تیمهای توسعه که به تفکیک وظایف نیاز دارند، مناسب است. اما باید بهینهسازی لازم برای جلوگیری از کاهش عملکرد انجام شود.
source
@Syntax_fa
Linkedin
Sina Riyahi on LinkedIn: #csharp #efcore #dotnet #dotnetcore
Top 6 Architectural Patterns
Monolithic Architecture:
In a monolithic architecture, all components of an application are integrated into a single, unified…
Monolithic Architecture:
In a monolithic architecture, all components of an application are integrated into a single, unified…
Forwarded from AI ML Repo (Zahra Gholami)
https://aistudio.google.com/
به جای chat gpt open ai از این ابزار استفاده کنید، آپدیت های بروز تری نسبت به chat gpt داره
به جای chat gpt open ai از این ابزار استفاده کنید، آپدیت های بروز تری نسبت به chat gpt داره
Google
Google AI Studio
The fastest path from prompt to production with Gemini
Forwarded from Syntax | سینتکس (Daimon)
This media is not supported in your browser
VIEW IN TELEGRAM
6 الگوی برتر معماری نرمافزار
معماری مونولیتیک (Monolithic Architecture)
در معماری مونولیتیک، تمام اجزای یک برنامه در یک کدبیس واحد و یکپارچه ترکیب میشوند. این رویکرد، فرآیند استقرار (Deployment) را ساده کرده و برای برنامههای کوچک مدیریت آن آسانتر است. با این حال، با رشد برنامه، این معماری میتواند سنگین و پیچیده شود، به طوری که مقیاسپذیری و نگهداری آن دشوار میگردد. هر تغییری در بخشی از برنامه ممکن است نیازمند استقرار دوباره کل سیستم باشد.
این معماری برای پروژههای کوچک و تیمهای کوچک مناسب است، اما برای پروژههای بزرگتر، به دلیل وابستگیهای زیاد میان اجزاء، مدیریت تغییرات بسیار دشوار میشود.
الگوی (Controller-Worker Pattern)
این الگو منطق کنترل (Control Logic) را از منطق پردازش (Processing Logic) جدا میکند. کنترلر وظیفه مدیریت درخواستهای ورودی، جریان دادهها و تخصیص وظایف به اجزای کارگر (Worker) را بر عهده دارد. اجزای کارگر وظایف پردازشی واقعی را انجام میدهند. این الگو برای مدیریت وظایف غیرهمزمان (Asynchronous Tasks) مفید است و میتواند مقیاسپذیری را با امکان اجرای همزمان چندین نمونه از اجزای کارگر بهبود بخشد.
مناسب برای سیستمهایی است که بار پردازشی غیرهمزمان دارند، مانند پردازش صفها (Queues) یا مدیریت درخواستهای سنگین.
معماری میکروسرویسها (Microservices Architecture)
معماری میکروسرویسها برنامه را به سرویسهای کوچک و مستقل تقسیم میکند که از طریق APIهای مشخص با یکدیگر ارتباط برقرار میکنند. هر سرویس مسئول یک قابلیت خاص از کسبوکار است و میتواند بهطور مستقل توسعه، استقرار و مقیاسپذیری شود. این معماری انعطافپذیری بیشتری فراهم میکند و امکان استفاده از فناوریهای مختلف برای سرویسهای مختلف را میدهد. اما مدیریت سرویسها و ارتباط بین آنها میتواند پیچیدگیهایی به همراه داشته باشد.
این معماری مناسب سازمانهایی است که نیاز به توسعه سریع و مقیاسپذیری خدمات دارند. اما نیازمند ابزارهای مناسب برای نظارت، هماهنگی و مدیریت ارتباطات میان سرویسها است.
مدل (Model-View-Controller یا MVC)
الگوی MVC یک برنامه را به سه بخش مرتبط تقسیم میکند:
- مدل (Model): وظیفه مدیریت دادهها و منطق کسبوکار را دارد.
- نما (View): دادهها را به کاربر نمایش میدهد.
- کنترلر (Controller): ورودی کاربر را مدیریت کرده و با مدل تعامل دارد.
این جداسازی باعث سازماندهی بهتر کد میشود و مدیریت و مقیاسپذیری برنامه، بهویژه در توسعه وب، را آسانتر میکند.
این الگو در اکثر فریمورکهای وب مانند Django و Ruby on Rails استفاده میشود و برای پروژههایی که نیاز به تعامل زیاد با کاربر دارند، ایدهآل است.
معماری رویداد-محور (Event-Driven Architecture)
در معماری رویداد-محور، اجزا از طریق تولید و مصرف رویدادها با یکدیگر ارتباط برقرار میکنند. هنگامی که یک رویداد رخ میدهد (مانند یک اقدام کاربر یا تغییری در سیستم)، رویداد های خاصی در سیستم ایجاد میشود و دیگر اجزای سیستم نسبت به رویداد ها اکشن مناسبی که نیاز دارند را انجام می دهند. این معماری بسیار جدا از هم (Decoupled) است و مقیاسپذیری و انعطافپذیری بیشتری فراهم میکند، چرا که اجزا میتوانند بهطور مستقل تکامل یابند.
این معماری در سیستمهای توزیعشده بسیار مفید است.
معماری لایهای (Layered Architecture)
در معماری لایهای، برنامه به لایههای مجزا با وظایف مشخص تقسیم میشود. لایههای رایج شامل موارد زیر هستند:
- لایه ارائه (Presentation Layer): وظیفه نمایش داده به کاربر.
- لایه منطق کسبوکار (Business Logic Layer): مدیریت منطق اصلی برنامه.
- لایه دسترسی به داده (Data Access Layer): مدیریت تعامل با پایگاه داده.
هر لایه تنها با لایه مجاور خود ارتباط برقرار میکند که باعث جداسازی وظایف (Separation of Concerns) میشود. این الگو نگهداری را آسان کرده و به تیمها اجازه میدهد بهطور مستقل روی لایههای مختلف کار کنند. با این حال، وجود لایههای متعدد ممکن است باعث کاهش عملکرد به دلیل سربار ناشی از ارتباط میان لایهها شود.
این معماری برای سیستمهای بزرگ و تیمهای توسعه که به تفکیک وظایف نیاز دارند، مناسب است. اما باید بهینهسازی لازم برای جلوگیری از کاهش عملکرد انجام شود.
source
@Syntax_fa
معماری مونولیتیک (Monolithic Architecture)
در معماری مونولیتیک، تمام اجزای یک برنامه در یک کدبیس واحد و یکپارچه ترکیب میشوند. این رویکرد، فرآیند استقرار (Deployment) را ساده کرده و برای برنامههای کوچک مدیریت آن آسانتر است. با این حال، با رشد برنامه، این معماری میتواند سنگین و پیچیده شود، به طوری که مقیاسپذیری و نگهداری آن دشوار میگردد. هر تغییری در بخشی از برنامه ممکن است نیازمند استقرار دوباره کل سیستم باشد.
این معماری برای پروژههای کوچک و تیمهای کوچک مناسب است، اما برای پروژههای بزرگتر، به دلیل وابستگیهای زیاد میان اجزاء، مدیریت تغییرات بسیار دشوار میشود.
الگوی (Controller-Worker Pattern)
این الگو منطق کنترل (Control Logic) را از منطق پردازش (Processing Logic) جدا میکند. کنترلر وظیفه مدیریت درخواستهای ورودی، جریان دادهها و تخصیص وظایف به اجزای کارگر (Worker) را بر عهده دارد. اجزای کارگر وظایف پردازشی واقعی را انجام میدهند. این الگو برای مدیریت وظایف غیرهمزمان (Asynchronous Tasks) مفید است و میتواند مقیاسپذیری را با امکان اجرای همزمان چندین نمونه از اجزای کارگر بهبود بخشد.
مناسب برای سیستمهایی است که بار پردازشی غیرهمزمان دارند، مانند پردازش صفها (Queues) یا مدیریت درخواستهای سنگین.
معماری میکروسرویسها (Microservices Architecture)
معماری میکروسرویسها برنامه را به سرویسهای کوچک و مستقل تقسیم میکند که از طریق APIهای مشخص با یکدیگر ارتباط برقرار میکنند. هر سرویس مسئول یک قابلیت خاص از کسبوکار است و میتواند بهطور مستقل توسعه، استقرار و مقیاسپذیری شود. این معماری انعطافپذیری بیشتری فراهم میکند و امکان استفاده از فناوریهای مختلف برای سرویسهای مختلف را میدهد. اما مدیریت سرویسها و ارتباط بین آنها میتواند پیچیدگیهایی به همراه داشته باشد.
این معماری مناسب سازمانهایی است که نیاز به توسعه سریع و مقیاسپذیری خدمات دارند. اما نیازمند ابزارهای مناسب برای نظارت، هماهنگی و مدیریت ارتباطات میان سرویسها است.
مدل (Model-View-Controller یا MVC)
الگوی MVC یک برنامه را به سه بخش مرتبط تقسیم میکند:
- مدل (Model): وظیفه مدیریت دادهها و منطق کسبوکار را دارد.
- نما (View): دادهها را به کاربر نمایش میدهد.
- کنترلر (Controller): ورودی کاربر را مدیریت کرده و با مدل تعامل دارد.
این جداسازی باعث سازماندهی بهتر کد میشود و مدیریت و مقیاسپذیری برنامه، بهویژه در توسعه وب، را آسانتر میکند.
این الگو در اکثر فریمورکهای وب مانند Django و Ruby on Rails استفاده میشود و برای پروژههایی که نیاز به تعامل زیاد با کاربر دارند، ایدهآل است.
معماری رویداد-محور (Event-Driven Architecture)
در معماری رویداد-محور، اجزا از طریق تولید و مصرف رویدادها با یکدیگر ارتباط برقرار میکنند. هنگامی که یک رویداد رخ میدهد (مانند یک اقدام کاربر یا تغییری در سیستم)، رویداد های خاصی در سیستم ایجاد میشود و دیگر اجزای سیستم نسبت به رویداد ها اکشن مناسبی که نیاز دارند را انجام می دهند. این معماری بسیار جدا از هم (Decoupled) است و مقیاسپذیری و انعطافپذیری بیشتری فراهم میکند، چرا که اجزا میتوانند بهطور مستقل تکامل یابند.
این معماری در سیستمهای توزیعشده بسیار مفید است.
معماری لایهای (Layered Architecture)
در معماری لایهای، برنامه به لایههای مجزا با وظایف مشخص تقسیم میشود. لایههای رایج شامل موارد زیر هستند:
- لایه ارائه (Presentation Layer): وظیفه نمایش داده به کاربر.
- لایه منطق کسبوکار (Business Logic Layer): مدیریت منطق اصلی برنامه.
- لایه دسترسی به داده (Data Access Layer): مدیریت تعامل با پایگاه داده.
هر لایه تنها با لایه مجاور خود ارتباط برقرار میکند که باعث جداسازی وظایف (Separation of Concerns) میشود. این الگو نگهداری را آسان کرده و به تیمها اجازه میدهد بهطور مستقل روی لایههای مختلف کار کنند. با این حال، وجود لایههای متعدد ممکن است باعث کاهش عملکرد به دلیل سربار ناشی از ارتباط میان لایهها شود.
این معماری برای سیستمهای بزرگ و تیمهای توسعه که به تفکیک وظایف نیاز دارند، مناسب است. اما باید بهینهسازی لازم برای جلوگیری از کاهش عملکرد انجام شود.
source
@Syntax_fa
👍1
Forwarded from DevTwitter | توییت برنامه نویسی
بفرمایید Harper
هارپر یک ابزار بررسی گرامر انگلیسی هست که طبق ادعادی نویسندهش از نظر سرعت و دقت، توان رقابت با Grammarly رو داره!
حریم خصوصی رو رعایت میکنه و البته رایگان و کدباز هست.
گیتهاب:
https://github.com/automattic/harper
سایت اصلی:
https://writewithharper.com
@DevTwitter | <Morteza Geransayeh/>
هارپر یک ابزار بررسی گرامر انگلیسی هست که طبق ادعادی نویسندهش از نظر سرعت و دقت، توان رقابت با Grammarly رو داره!
حریم خصوصی رو رعایت میکنه و البته رایگان و کدباز هست.
گیتهاب:
https://github.com/automattic/harper
سایت اصلی:
https://writewithharper.com
@DevTwitter | <Morteza Geransayeh/>
Forwarded from Morteza Bashsiz مرتضی باشسیز (Morteza Bashsiz)
درود دوستان
من تمامی اسکریپتهایی که توی این دوره دیباگ استفاده میکنم رو گذاشتم توی ریپوزیتوری یوتیوبم توی گیتهاب
اگه دوست دارید که خودتون تمرین کنید میتونید استفاده کنید
https://github.com/MortezaBashsiz/YouTube/tree/main/Debug
من تمامی اسکریپتهایی که توی این دوره دیباگ استفاده میکنم رو گذاشتم توی ریپوزیتوری یوتیوبم توی گیتهاب
اگه دوست دارید که خودتون تمرین کنید میتونید استفاده کنید
https://github.com/MortezaBashsiz/YouTube/tree/main/Debug
GitHub
YouTube/Debug at main · MortezaBashsiz/YouTube
Contribute to MortezaBashsiz/YouTube development by creating an account on GitHub.
Forwarded from محتوای آزاد سهراب
این ویدئو رو پارسال درمورد ماستادون و فدیورس ضبط کردم، اگر قصد دارید داخلشون حساب بسازید توصیه میکنم تماشا کنید.
تماشا از پیرتوب
@SohrabContents
تماشا از پیرتوب
@SohrabContents
Forwarded from CleverDevs (Mammad)
یکی از بچه های چنل در حال توسعه بکاند فروشگاهی هست. این پروژه با nestjs و mongodb در حال توسعهست. داکیومنتش با swagger توسعه داده میشه (فایل postman هم موجوده). در پروژه از unit test استفاده شده تا دوستانی که مایل به همکاری هستن به راحتی به پروژه بپیوندن. پروژه روی داکر هست که اگه از دوستان کسی مایل به تست بود، به راحتی با داکر پروژه رو اجرا کنه. دوستان فرانت کاری که دنبال بک اند برای نمونه کارشون میگردن میتونن از این ریپو استفاده کنن.
لینک گیت هاب :
https://github.com/AliDeWeb/Shop-Center
#openSource
@CleverDevs - @CleverDevsGp
لینک گیت هاب :
https://github.com/AliDeWeb/Shop-Center
#openSource
@CleverDevs - @CleverDevsGp
Forwarded from Laravel News
Converting Laravel Models to JSON for API Responses https://laravel-news.com/toJson
Laravel News
Converting Laravel Models to JSON for API Responses - Laravel News
Discover how Laravel's toJson() method simplifies model-to-JSON conversion. Learn to customize your API responses while leveraging both explicit conversion and Laravel's automatic serialization features.
Forwarded from DevTwitter | توییت برنامه نویسی
وقتی ویندوز 98 میزبان هوش مصنوعی میشود؛ سفر به گذشته برای آینده!
تصور کنید یک کامپیوتر با Pentium II و فقط 128 مگابایت رم، در حال اجرای یک مدل زبانی مثل Llama 2! تیم EXO Labs این ایده جذاب رو عملی کرده و نتیجهاش یه ترکیب شگفتانگیز از نوستالژی و تکنولوژیه.
با کمک کد سادهای از آندری کارپاتی، این سیستم میتونه با سرعت 35.9 توکن بر ثانیه متن تولید کنه.
فایلها با FTP منتقل میشن و کامپایل کدها با ابزارهایی مثل Borland C++ 5.02 انجام شده.
در واقع هوش مصنوعی رو روی کانفیگی بالا آورده که حتی انتقال فایل بهش از طریق USB ممکن نیست
البته کار این تیم جدای از جنبه فانش ، میخواد نشون بده هوش مصنوعی نباید فقط در انحصار شرکتهای بزرگ باشه. این پروژه، قدمیه برای دسترسپذیر کردن هوش مصنوعی برای همه!
@DevTwitter | <breaking news/>
تصور کنید یک کامپیوتر با Pentium II و فقط 128 مگابایت رم، در حال اجرای یک مدل زبانی مثل Llama 2! تیم EXO Labs این ایده جذاب رو عملی کرده و نتیجهاش یه ترکیب شگفتانگیز از نوستالژی و تکنولوژیه.
با کمک کد سادهای از آندری کارپاتی، این سیستم میتونه با سرعت 35.9 توکن بر ثانیه متن تولید کنه.
فایلها با FTP منتقل میشن و کامپایل کدها با ابزارهایی مثل Borland C++ 5.02 انجام شده.
در واقع هوش مصنوعی رو روی کانفیگی بالا آورده که حتی انتقال فایل بهش از طریق USB ممکن نیست
البته کار این تیم جدای از جنبه فانش ، میخواد نشون بده هوش مصنوعی نباید فقط در انحصار شرکتهای بزرگ باشه. این پروژه، قدمیه برای دسترسپذیر کردن هوش مصنوعی برای همه!
@DevTwitter | <breaking news/>