Syntax | سینتکس

داکیومنت داکر اینو میگه: internal By default, Compose provides external connectivity to networks. internal, when set to true, lets you create an externally isolated network. برای حل این مسئله، می‌توانیم از شبکه‌های داخلی (internal network) در Docker Compose استفاده کنیم. شبکه داخلی یک شبکه‌ای است که داکر فراهم می‌کند و ارتباط سرویس‌ها فقط در داخل همان شبکه امکان‌پذیر است. به این ترتیب، سرویس‌ها کاملاً ایزوله می‌شوند و هیچ ارتباطی با خارج از شبکه داکر (مانند هاست یا اینترنت) برقرار نمی‌کنند، حتی اگر به اشتباه پورت‌هایی در فایل Compose تعریف شود. 1. ایجاد شبکه داخلی در فایل `docker-compose.yml`: در فایل Docker Compose، می‌توانید یک شبکه داخلی تعریف کنید. در این شبکه، سرویس‌ها فقط می‌توانند با یکدیگر ارتباط برقرار کنند و هیچ ارتباطی با شبکه هاست یا اینترنت ندارند. مثال:

   version: '3.9'
   services:
     service1:
       image: my-image-1
       networks:
         - internal_network
     service2:
       image: my-image-2
       networks:
         - internal_network

   networks:
     internal_network:
       internal: true
   

توضیحات: - در بخش networks`، یک شبکه به نام `internal_network تعریف شده و ویژگی internal: true به آن اضافه شده است. - این شبکه فقط برای ارتباط داخلی بین سرویس‌های تعریف‌شده در Docker Compose در دسترس است. - هیچ پورت خارجی (حتی اگر در بخش ports تعریف شده باشد) از خارج شبکه داکر قابل دسترسی نخواهد بود. #docker #docker_compose @Syntax_fa

سوال درباره داکر و داکر کمپوز سوال: فرض کنید ما چند سرویس داریم که در یک پروژه با استفاده از Docker Compose مدیریت می‌شوند. این سرویس‌ها نیازی به ارتباط با خارج از شبکه داخلی داکر (مانند شبکه هاست یا اینترنت) ندارند و فقط باید به‌صورت داخلی با یکدیگر ارتباط برقرار کنند. حتی اگر به اشتباه پورت‌هایی برای آن‌ها در فایل Docker Compose تعریف شود (مانند ports)، نباید این پورت‌ها از بیرون شبکه داکر در دسترس باشند. چگونه می‌توانیم چنین محدودیتی اعمال کنیم و اطمینان حاصل کنیم که سرویس‌ها کاملاً ایزوله هستند و فقط در شبکه داخلی داکر قابل دسترسی‌اند؟ (جواب و راه حلی پیشنهادی پست بعدی گذاشته میشه) #docker #docker_compose @Syntax_fa

چند نکته درباره Dockerfile ۱. بدون دسترسی روت: - اجرای کانتینر با کاربر غیر روت برای امنیت بیشتر ۲. ساخت چند مرحله‌ای (Multistage Build): - کاهش حجم نهایی ایمیج - جداسازی محیط build از محیط اجرا مثال:

FROM golang:1.23 AS build
WORKDIR /src
COPY main.go .
RUN go build -o /bin/hello ./main.go

FROM scratch
COPY --from=build /bin/hello /bin/hello

CMD ["/bin/hello"]

۳. استفاده از Distroless یا From Scratch: - حذف ابزارهای غیرضروری برای کاهش سطح حمله - استفاده از ایمیج‌های پایه حداقلی مثال:

FROM gcr.io/distroless/nodejs
COPY --from=builder /app/dist .
CMD ["app.js"]

۴. استفاده از ایمیج‌های مطمئن: - استفاده از ایمیج‌های رسمی از Docker Hub - بررسی منبع و تاریخچه ایمیج‌ها ۵. به‌روزرسانی منظم ایمیج: - به‌روزرسانی مرتب پایه ایمیج برای دریافت پچ‌های امنیتی - استفاده از CI/CD برای ساخت خودکار ایمیج‌های جدید ۶. پورت‌های در معرض (Exposed Ports): - فقط پورت‌های ضروری را expose کنید - مستندسازی پورت‌های مورد نیاز مثال:

EXPOSE 8080

۷. عدم قرار دادن کلیدها و رمزها در Dockerfile - استفاده از secrets یا متغیرهای محیطی مثال:

# bad idea
ENV DB_PASSWORD=secretpass

# recommended
ARG DB_PASSWORD

۸. مدیریت لایه‌ها (Layer Sanity): - ترکیب دستورات مرتبط برای کاهش تعداد لایه‌ها - حذف فایل‌های موقت در همان لایه مثال:

RUN apt-get update && \
    apt-get install -y package1 package2 && \
    rm -rf /var/lib/apt/lists/*

۹. برچسب‌های متادیتا: - افزودن اطلاعات مفید درباره ایمیج مثال:

LABEL maintainer="email@example.com"
LABEL version="1.0"
LABEL description="Application description"

نکات تکمیلی: - همیشه از .dockerignore برای ایگنور شدن فایل‌های غیرضروری استفاده کنید - دستورات را به ترتیب بهینه قرار دهید (از کمترین تغییر به بیشترین) - از کش Docker به درستی استفاده کنید #docker @Syntax_fa

این ویدیو از آتیش سوزی لس آنجلس رو اگه از یه کانال اطلاع رسانی بازی میدیدیم فک میکردم با آنریل انجین برای سری جدید Resident Evil ساختن @normal_developer

در وینوز خبیث چگونه داکر که یک linux container هستش اجرا میشه؟ قبل از 2016: در ابتدا، Docker فقط برای Linux طراحی شده بود و روی Windows قابل اجرا نبود🫠. در آن زمان، توسعه‌دهندگان Windows برای استفاده از Docker مجبور بودند: 1. یا از یک ماشین مجازی Linux جداگانه استفاده کنند 2. یا از ابزارهایی مثل VirtualBox استفاده کنند 3. یا تصمیم عاقلانه میگرفتن لینوکسی میشدن 2016 - معرفی Docker for Windows: در سال 2016، Docker یک راهکار رسمی برای Windows ارائه کرد که شامل دو بخش اصلی بود: 1. Docker Desktop for Windows: - یک نرم‌افزار یکپارچه که شامل تمام اجزای مورد نیاز برای اجرای Docker بود - از Hyper-V (مجازی‌ساز رسمی Microsoft) استفاده می‌کرد - یک Moby VM (ماشین مجازی سبک Linux) را به صورت خودکار مدیریت می‌کرد 2. معماری دو لایه: - لایه Windows: شامل Docker Client که رابط کاربری و CLI را در اختیار کاربر قرار می‌داد - لایه Linux (Moby VM): شامل Docker Daemon که مسئول اصلی مدیریت کانتینرها بود نحوه کار: 1. کاربر در Windows دستورات Docker را اجرا می‌کند 2. Docker Client این دستورات را به Moby VM منتقل می‌کند 3. Docker Daemon در Moby VM دستورات را پردازش کرده و کانتینرها را مدیریت می‌کند 4. تمام کانتینرهای Linux در این VM اجرا می‌شوند و از kernel آن استفاده می‌کنند مزایای این معماری: - کانتینرهای Linux دقیقاً مثل Linux اصلی کار می‌کنند - مدیریت منابع بهتر و کارایی بالاتر نسبت به استفاده از VirtualBox - یکپارچگی بهتر با Windows - نصب و راه‌اندازی ساده‌تر تغییرات بعدی: بعد از 2016، Docker قابلیت‌های جدیدی اضافه کرد: 1. Windows Containers: امکان اجرای کانتینرهای native ویندوزی 2. WSL2 Integration: یکپارچگی با Windows Subsystem for Linux نسخه 2 3. Hyper-V Isolation: لایه امنیتی اضافه برای جداسازی بهتر کانتینرها در نمودار بالا هم دقیقاً همین معماری نشان داده شده: - سمت چپ: محیط Windows که Docker Client در آن قرار دارد - سمت راست: Moby VM که Docker Daemon و کانتینرهای Linux را میزبانی می‌کند - ارتباط بین این دو از طریق یک پروتکل شبکه انجام می‌شود توضیحات مایکروسافت خبیث #docker @Syntax_fa

توی پایتون بجای isinstance از singledispatch استفاده کن! ۱. ابتدا دو کلاس با استفاده از @dataclass تعریف میکنیم:

@dataclass
class UserCanceledSubscription:
    username: str

@dataclass
class UserSubscribed:
    username: str

این‌ها دو نوع ایونت هستند: یکی برای زمانی که کاربر مشترک می‌شود و دیگری برای زمانی که اشتراکش را لغو می‌کند. ۲. روش اول با استفاده از isinstance:

def process(event):
    if isinstance(event, UserSubscribed):
        print(f"Enable access to user {event.username}")
    elif isinstance(event, UserCanceledSubscription):
        print(f"Disable access to user {event.username}")

در این روش، برای هر نوع رویداد یک شرط if نوشته شده که نوع رویداد را چک می‌کند. ۳. روش دوم با استفاده از singledispatch:

@singledispatch
def process(event):
    pass

@process.register(UserCanceledSubscription)
def _(event):
    print(f"Disable access to user {event.username}")

@process.register(UserSubscribed)
def _(event):
    print(f"Enable access to user {event.username}")

در این روش، برای هر نوع رویداد یک تابع جداگانه تعریف می‌شود که فقط برای آن نوع خاص اجرا می‌شود. مزایای استفاده از singledispatch: ۱. کد تمیزتر: به جای زنجیره‌ای از `if/elif`، هر منطق در یک تابع جداگانه قرار می‌گیرد. ۲. قابلیت توسعه بهتر: اضافه کردن نوع جدید فقط نیاز به اضافه کردن یک تابع جدید دارد، نه تغییر کد موجود. ۳. جداسازی مسئولیت‌ها: هر تابع فقط مسئول پردازش یک نوع خاص است. ۴. کاهش پیچیدگی: به جای یک تابع بزرگ با شرط‌های متعدد، چندین تابع کوچک و ساده داریم. نحوه کار: - @singledispatch یک تابع پایه تعریف می‌کند - @process.register() توابع مختلف را برای انواع مختلف ورودی ثبت می‌کند - در زمان اجرا، بر اساس نوع ورودی، تابع مناسب فراخوانی می‌شود کاربرد این الگو در مواردی مثل: - پردازش انواع مختلف پیام‌ها یا رویدادها - تبدیل داده‌ها بین فرمت‌های مختلف - اعمال عملیات‌های متفاوت روی انواع مختلف داده - پیاده‌سازی الگوی Observer یا Event Handler نمونه استفاده نهایی:

events = [
    UserSubscribed(username="johndoe"),
    UserCanceledSubscription(username="johndoe"),
]

for event in events:
    process(event)

این کد به طور خودکار تابع مناسب را برای هر نوع رویداد فراخوانی می‌کند. #python #singledispatch @Syntax_fa

سوال مصاحبه ای درباره ذاکر با توضیح کامل چرا وقتی یک کانتینر از یک ایمیجی رو بالا میاریم، نمیتونیم اون ایمیج رو پاک کنیم؟ زمانی که شما یک کانتینر را از یک ایمیج (Image) در Docker بالا می‌آورید، امکان حذف آن ایمیج تا زمانی که کانتینر مرتبط با آن در حال اجرا یا وجود داشته باشد امکان پذیر نیست. این رفتار به دلیل معماری Docker و نحوه مدیریت داده‌ها از طریق مکانیزم‌هایی مانند Copy-on-Write (COW) و UnionFS اتفاق می‌افتد. در Docker، ایمیج‌ها به‌عنوان قالب‌های فقط خواندنی (Read-Only) عمل می‌کنند که شامل تمام فایل‌ها، نرم‌افزارها و تنظیمات مورد نیاز برای اجرای یک برنامه هستند. وقتی یک کانتینر از یک ایمیج بالا می‌آید: - ایمیج به‌عنوان پایه (Base) عمل می‌کند. - کانتینر یک لایه نوشتنی (Writable Layer) به بالای ایمیج اضافه می‌کند. این لایه نوشتنی به کانتینر اجازه می‌دهد تغییراتی مانند ایجاد فایل‌ها یا تغییر تنظیمات را انجام دهد، بدون اینکه لایه‌های فقط خواندنی ایمیج اصلی تغییر کنند. Copy-on-Write (COW) داکر برای مدیریت تغییرات کانتینر از مکانیزم Copy-on-Write (COW) استفاده می‌کند. به این معنا که: - تا زمانی که نیازی به تغییر داده‌ها نباشد، کانتینر از لایه‌های موجود در ایمیج به‌صورت مستقیم استفاده می‌کند. - وقتی تغییری در یک فایل لازم باشد، آن فایل از لایه فقط خواندنی ایمیج به لایه نوشتنی کانتینر کپی می‌شود و سپس تغییرات اعمال می‌گردد. این روش باعث صرفه‌جویی در منابع می‌شود، زیرا تا زمانی که نیازی به تغییر نباشد، ایمیج و کانتینر از همان نسخه داده‌ها استفاده می‌کنند. UnionFS سیستم فایل UnionFS (Union File System) برای ترکیب چندین لایه سیستم فایل در یک نمای واحد (Single View) استفاده می‌شود. Docker از UnionFS برای ساخت ایمیج‌ها و کانتینرها استفاده می‌کند. نحوه کار به این صورت است: - ایمیج‌ها از چندین لایه تشکیل شده‌اند. - این لایه‌ها فقط خواندنی هستند و هر لایه تغییرات و افزوده‌هایی نسبت به لایه قبلی دارد. - وقتی یک کانتینر ایجاد می‌شود، یک لایه نوشتنی به بالای این لایه‌های فقط خواندنی اضافه می‌شود. بنابراین، از دید کانتینر، تمام این لایه‌ها به‌صورت یک سیستم فایل یکپارچه دیده می‌شوند. اما در واقعیت، لایه نوشتنی و لایه‌های فقط خواندنی جدا از هم هستند. https://en.wikipedia.org/wiki/UnionFS چرا ایمیج حذف نمی‌شود؟ وقتی یک کانتینر از یک ایمیج ایجاد می‌شود، آن کانتینر به لایه‌های ایمیج وابسته است. به همین دلیل، تا زمانی که کانتینر وجود دارد (حتی اگر متوقف شده باشد): - لایه‌های فقط خواندنی ایمیج در حال استفاده هستند. - اگر ایمیج حذف شود، کانتینر نمی‌تواند به لایه‌های مورد نیاز خود دسترسی پیدا کند و در نتیجه خراب می‌شود. Docker برای جلوگیری از این مشکل، اجازه حذف ایمیج‌هایی که در حال استفاده هستند را نمی‌دهد و در نهایت فقط میتوانید تگ آن را حذف کنید نه بادی ایمیج را. ارتباط Copy-on-Write و UnionFS - UnionFS امکان استفاده از چندین لایه سیستم فایل را فراهم می‌کند و باعث می‌شود ایمیج‌ها و کانتینرها به‌صورت مؤثری مدیریت شوند. - Copy-on-Write تضمین می‌کند که تنها زمانی تغییرات در داده‌ها ایجاد شوند که واقعاً لازم باشد، بدون تغییر لایه‌های اصلی (فقط خواندنی) ایمیج. این دو مکانیزم با هم کار می‌کنند تا Docker بتواند ایمیج‌ها و کانتینرها را به‌صورت کارآمد مدیریت کند. چگونه ایمیج را حذف کنیم؟ اگر بخواهید یک ایمیج را حذف کنید، ابتدا باید تمام کانتینرهای وابسته به آن را حذف کنید. مراحل کلی عبارتند از: 1. لیست کانتینرهای وابسته به ایمیج:

   docker ps -a --filter ancestor=<image_name_or_id>
   

2. حذف کانتینرهای وابسته:

   docker rm <container_id>
   

3. حذف ایمیج:

   docker rmi <image_name_or_id>
   

#docker #copy_on_write #union_file_system @Syntax_fa

استاد سنیور فول استک دولوپر میفرماید: هر کی تو گیتهاب فعاله برنامه نویس نیست حالا تو هعی پروژه بزن بذار تو گیتهاب #fun @Syntax_fa

دوستان اگه اپلیکیشن رو بصورت مونولیت مینیوسید، کار خوبی میکنید، اما aggregation pattern رو جدی بگیرید، کمک بزرگی میکنه به حفظ loosely coupled بودن ماژول و سرویس هاتون. یه اشتباه رایجی که باعث میشه خیلی راحت همه چیز در هم تنیده و coupled بشه نیازهای بیزینسی ای هست که دیتای aggregate شده از چند domain مختلف رو میخواد از شما. تو حالت مونولیت خیلی ساده ست که شما در هر domain به دیتابیس یه domain دیگه درخواست بزنی و یا حتی تو interactor/service دیگه یه متد جدید تعریف کنی که دیتای مد نظر رو بده. که معمولا باعث در هم تنیده شدن و چاق شدن سرویس هاتون میشه. بهتره سرویس یا همون interactorهاتون کارهای خیلی کوچیک و well-definedی رو انجام بدن و اگه نیازمندی های aggregationطور دارید، یه سری service دیگه بسازید که وابستگی خواهد داشت به سرویس های مختلف و دیتاهای raw رو میگیره و پردازش میکنه که دیتای نهایی رو آماده کنه. بعضی وقت ها از طریق gateway هم ممکنه بتونید aggregate کنید. بعضی وقت ها ممکنه تو همون لایه دلیوری (کنترلر) تون بتونید دو تا سرویس رو فراخوانی کنید و کار رو در بیارید، گاهی هم پیچیده تر میشه و لازمه یه سرویس(interactor) بنویسید که کار aggregation رو انجام بده https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation باز خود aggregate کردن حالت های مختلفی داره، اینجا میتونید بیشتر بخونید در موردش https://medium.com/geekculture/design-patterns-for-microservices-aggregation-pattern-1b8994516fa2 Source: https://t.me/gocasts @Syntax_fa

دنیا توسط نسل زد داره میچرخه ها

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

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

مقاله زیر به ما آموزش میده چطور 1,000,000 رکورد دیتا رو در 4 ثانیه در PostgreSQL ذخیره کنیم! https://www.timescale.com/learn/testing-postgres-ingest-insert-vs-batch-insert-vs-copy?ref=timescale.com #postgresql #database source @Syntax_fa

یه مدتی هست دارم سعی میکنم ترید کردن یاد بگیرم و پوزیشن های خیلی کوچیک باز میکنم و الان حدودا ۱۰ دلار تو اکانتم دارم. البته با ۱۵ دلار شروع کرده بودم :( میخوام یه کانال سیگنال دهی بزنم و برعکس هرکاری خودم کردمو بذارم اونجا ملت استفاده کنن. @normal_developer

اطلاعیه تیم سینتکس در راستای توسعه پروژه‌های برنامه‌نویسی خود، به دنبال جذب یک برنامه‌نویس فرانت‌اند حرفه‌ای و با تجربه است. اگر شما فردی هستید که به فریم‌ورک‌های وب تسلط دارید، دارای رزومه‌ای قوی و تعهد کاری بالا هستید، و همچنین روحیه تیمی و انگیزه برای یادگیری دارید، ما به شما نیاز داریم! شرایط عضویت در تیم: • بررسی رزومه شما توسط تیم سینتکس • ارائه یک صفحه لودینگ خلاقانه و سبک به عنوان آزمون نهایی برای عضویت کامل در تیم توجه: وب‌سایت تیم سینتکس در مرحله لانچ (اتصال به API) قرار دارد و هنوز به صورت عمومی منتشر نشده است. اگر شرایط فوق را دارید و مایل به پیوستن به تیم ما هستید، لطفاً به آیدی زیر: @Awmirsn پیام دهید تا لینک وب‌سایت سینتکس برای شما ارسال شود. پس از آن، ارزیابی خواهید کرد که آیا می‌توانید صفحه لودینگ متناسب با این وب‌سایت را طراحی کنید یا خیر. با تشکر و آرزوی موفقیت برای شما، تیم سینتکس

آشنایی با File and Directory Permissions در لینوکس یکبار برای همیشه در لینوکس، هر فایل و دایرکتوری دارای سطوح دسترسی (Permissions) است که مشخص می‌کند چه کسی می‌تواند به فایل یا دایرکتوری دسترسی داشته باشد و چه کاری با آن انجام دهد. این سطوح دسترسی برای سه دسته اصلی تعریف می‌شوند: 1. Owner (مالک فایل یا دایرکتوری) 2. Group (گروهی که فایل یا دایرکتوری به آن تعلق دارد) 3. Others (سایر کاربران سیستم) ساختار دسترسی‌ها در ابتدای هر فایل یا دایرکتوری در خروجی دستور ls -l، سطح دسترسی آن به صورت زیر نمایش داده می‌شود:

drwxrwxrwx

این سطح دسترسی از 10 کاراکتر تشکیل شده است: 1. اولین کاراکتر: نوع فایل را مشخص می‌کند: - - : فایل معمولی - d : دایرکتوری - l : لینک سمبلیک 2. 9 کاراکتر بعدی (سه گروه سه‌تایی): سطح دسترسی برای مالک، گروه و سایرین را نشان می‌دهد: - r : اجازه خواندن (Read) - w : اجازه نوشتن (Write) - x : اجازه اجرا (Execute) جدول باینری و مقادیر اعداد هر سطح دسترسی را می‌توان به یک عدد باینری و سپس یک مقدار عددی تبدیل کرد. جدول زیر این مفهوم را نشان می‌دهد: | مقدار عددی | سطح دسترسی | باینری | |------------|------------|---------| | 7 | rwx | 111 | | 6 | rw- | 110 | | 5 | r-x | 101 | | 4 | r-- | 100 | | 3 | -wx | 011 | | 2 | -w- | 010 | | 1 | --x | 001 | | 0 | --- | 000 مثال: chmod 777 دستور chmod برای تغییر سطح دسترسی فایل‌ها و دایرکتوری‌ها استفاده می‌شود. در مثال chmod 777: - اولین عدد 7: سطح دسترسی مالک (Owner) است. - دومین عدد 7: سطح دسترسی گروه (Group) است. - سومین عدد 7: سطح دسترسی سایرین (Others) است. سطح دسترسی هر عدد به صورت زیر تعریف می‌شود:

rwx | rwx | rwx

این به این معناست که: - مالک: می‌تواند بخواند، بنویسد و اجرا کند. - گروه: می‌تواند بخواند، بنویسد و اجرا کند. - سایرین: می‌توانند بخوانند، بنویسند و اجرا کنند. دسترسی‌های محدودتر حال اگر بخواهیم دسترسی محدودتری تعریف کنیم، می‌توانیم از مقادیر پایین‌تر استفاده کنیم: - chmod 644: - مالک: rw- (خواندن و نوشتن) - گروه: r-- (فقط خواندن) - سایرین: r-- (فقط خواندن) - chmod 755: - مالک: rwx (خواندن، نوشتن و اجرا) - گروه: r-x (خواندن و اجرا) - سایرین: r-x (خواندن و اجرا) - chmod +x: دسترسی execute به مالک و گروه و دیگر کاربران - chmod -r: دسترسی read رو از مالک و گروه و دیگر کاربران میگیریم نکته درباره دایرکتوری‌ها برای دایرکتوری‌ها: - r: به کاربر اجازه می‌دهد محتویات دایرکتوری را مشاهده کند. - w: به کاربر اجازه می‌دهد فایل‌ها را حذف یا اضافه کند. - x: اجازه ورود به دایرکتوری را می‌دهد. #file_and_directory_permission @Syntax_fa