Forwarded from Rust for Python developers
Fish shell رو با بازنویسی کامل روی
Rust برای نسخه 4 خواهیم داشت.ازون گیتهابای پر از درس هست که خیلی خوب میشه سورس کدش رو خوند.
پروژه
Limbo رو که یادتون هست ؟https://news.1rj.ru/str/pyrust/110
Telegram
Rust for Python developers
این پروژه limbo خیلی باحاله و دانشگاهیه برای آموزش crate های مختلف؛ سورس کدش رو بخونید
Limbo Github
داستان اینه که اومدن گفتن SQLite رو بهتر مینویسیم و با یک زبان امن که خب گزینهاش شده Rust و اینبار همه اجازه دارند کد Contribute کنند.
من خود پروژه رو…
Limbo Github
داستان اینه که اومدن گفتن SQLite رو بهتر مینویسیم و با یک زبان امن که خب گزینهاش شده Rust و اینبار همه اجازه دارند کد Contribute کنند.
من خود پروژه رو…
Forwarded from Python Hints
چون پرسیدید چرا (تو گروه توضیح دادم همون رو میذارم اینجا) :
تعداد پروژههای همزمان من زیاده و خیلی هم طرفدار استفاده از تولز نیستم
سری آخری که از
موقعی که تعداد پروژههای همزمان زیاد میشه :
۱- کندی شدیدی توی
۲- مصرف رم خیلی زیاد میشه
۳- ی وقتایی حتی خود به خود
و ...
که همگی این ها مشکلات اساسی مربوط به الکترون هست.
مختصرش این بود.
آیا
آیا باید یاد گرفت ؟ نه
ولی اگر کندی
—————————————————————————
چرا پایچارم نه ؟
سعی کن باهاش روی
بعد اینجوری هم هست که؛ تا دستت میخوره روش میگه علی الحساب ی ۴-۶ گیگ رم بده بعد میبینم چیکار داری.
تعداد پروژههای همزمان من زیاده و خیلی هم طرفدار استفاده از تولز نیستم
سری آخری که از
vim زدم بیرون هم برای این بود که همه تنظیماتم بدون بکاپ بود و هاردم سوخت (هیچوقت حال نداشتم تنظیم کنم) و هم اینکه خیلی از پلاگینهای الان هم نبود.موقعی که تعداد پروژههای همزمان زیاد میشه :
۱- کندی شدیدی توی
vscode دارم۲- مصرف رم خیلی زیاد میشه
۳- ی وقتایی حتی خود به خود
vscode بسته میشدو ...
که همگی این ها مشکلات اساسی مربوط به الکترون هست.
مختصرش این بود.
آیا
vim بدرد همه میخوره ؟ نه آیا باید یاد گرفت ؟ نه
ولی اگر کندی
vscode اذیت کننده بود یا lag , ... داشتید.—————————————————————————
چرا پایچارم نه ؟
سعی کن باهاش روی
python, rust, javanoscript کار کنی 😂بعد اینجوری هم هست که؛ تا دستت میخوره روش میگه علی الحساب ی ۴-۶ گیگ رم بده بعد میبینم چیکار داری.
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