✨ Github Actions Build and Test

🌚 قسمت اول که بتونیم یه گیتهاب اکشن بسیارساده برای تست و بیلد کردن پروژه هامون استفاده کنیم. مهم مفاهیم اصلیه که روش بیشتر وقت گذاشتیم و سعی کردم توضیحی کامل و جامع داشته باشه.

مدت ویدیو: 30 دقیقه
لینک ویدیو :

https://youtu.be/CF-JenvUKwQ

تاریخ فریاد ساکت حقیقت است. هیچ دیواری در برابر زمان استوار نمانده.

برای یک کاری نیاز داشتیم به استفاده از مانگو در دات نت، زحمت آنالیز پرفرمنسی بین ef و mongo driver به عهده آرین عزیزم بود، ببینید و دقت کنید :)
پیام آرین با این گزارش :
"من برای بررسی پرفومنس های mongo، توی هردو حالت درایور رسمی و همینطور EF یه دیتابیس سمپل اوپن سورس پیدا کردم
یکی از کالکشن هاش 36K دیتا داشت و من اکثر عملیات های مورد نیاز رو بنچمارک کردم
نتیجه‌ش شد این گزارش
"

🔵 عنوان مقاله
500 Milliseconds on Planning? How Statistics Slowed Down a Query 20 Times Over

🟢 خلاصه مقاله:
در یک سیستم پایگاه داده، ممکن است یک کوئری بسیار سریع اجرا شود، اما زمان لازم برای برنامه‌ریزی و آماده‌سازی اجرای آن بسیار طولانی‌تر باشد. در این مقاله، به یکی از این موارد جالب اشاره می‌شود که نشان می‌دهد چگونه یک عملیات برنامه‌ریزی با استفاده نادرست از بهینه‌ساز پایگاه داده PostgreSQL می‌تواند سرعت اجرای یک کوئری را تا ۲۰ برابر کاهش دهد. تصور کنید که یک کوئری تنها در عرض چند میلی‌ثانیه اجرا می‌شود، اما فرآیند برنامه‌ریزی آن بیش از نیم ثانیه زمان می‌برد. این اختلاف زمانی بسیار قابل توجه است و می‌تواند تاثیر زیادی بر عملکرد کل سیستم بگذارد.

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

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

#پایگاه_داده #بهینه‌سازی #PostgreSQL #کارایی

🟣لینک مقاله:
https://postgresweekly.com/link/180190/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

منم این مشکل قط شدن وای فای رو زیاد داشتم.

بهتره که داده‌هامون رو براساس نیازمندی و رفتار کاربر باهاشون تفکیک کنیم!

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

https://discord.com/blog/how-discord-stores-billions-of-messages

https://discord.com/blog/how-discord-stores-trillions-of-messages

سال 2017 دیسکورد روزانه چند میلیارد پیام رو مدیریت میکرد که تا سال 2023 به چند تریلیون پیام رسیده این عدد. نکته‌ای که توجه‌ام رو جلب کرد نحوه تقسیم پیام‌ها بود. دیسکورد اومد یه سری گزارش تهیه کرد تا بتونه نحوه رفتار کاربرهاش رو بررسی کنه. از این گزارش چه جور داده‌ای درومده؟ اینکه چه کانال‌هایی (یا به زبان دیسکورد سرورهایی) چه میزان پیام بر اساس تعداد کاربر، نوع و موضوع کانال و دسته بندی‌های این شکلی وجود دارن.
بر اساس این گزارش هر دسته از کانال چالش‌های خودش رو داشته.

نکته‌ای که برام جذاب بود، جدا از نحوه‌ی حل چالش‌ها، همین تقسیم نوع کاربری و رفتار محور داده بود. یه عادتی که ما داریم معمولا اینه که به همه چی موقع طراحی سیستم خیلی کلی نگاه میکنیم. این موضوع بخصوص وقتی داریم سیستم‌مون رو گسترده‌تر میکنیم به چشم میاد.
توی کتاب Designing Data-intensive Applications هم این موضوع رو کم و بیش میبینیم. توی فصل دوم کتاب از مثال صفحه اول توییتر استفاده میکنه و میاد تخمین میزنه که اکثر کاربرها، سلبریتی یا اینفلوئنسر نیستن و مثلا حدود 200 تا حساب رو دنبال میکنن، اما افرادی هم هستن که مثلا 100 میلیون دنبال کننده دارن.
موقع طراحی سیستم باید این تقسیم بندی رو قائل بشیم. چرا؟ چون ما نمیخوایم سیستمی رو طراحی کنیم که مثلا همه‌ی کاربرهاش 100 میلیون دنبال کننده دارن. میخوایم سیستمی رو طراحی کنیم که به طور متوسط کاربرهاش مثلا 200 نفر دنبال کننده دارن، اما افرادی هم هستند که 100 میلیون نفر دنبالشون میکنن. این تفکیک میتونه روی تصمیمات اساسی که برای سیستم میگیریم اثر چشمگیری بزاره.

@ever_code

تو دوران جنگ سرور بلاگمو آوردم پایین، حالا باید رو وی پی اس خودم بیارمش بالا
تا مدتی بلاگ پایینه، اما احتمالا تو dev.to بزارم پستارو
اگر کسی تجربه سایت استاتیک روی داکر داره بگه ممنون میشم اما احتمالا باید با آپاچی چیزی بیارمش بالا

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

با ghost آوردمش بالا

خب خبر خوب اینکه سایت بلاگ بالا اومد دوباره. اول با ghost راه انداختم، سرویس جذابیه، ولی تم های محدودی داره و میتونین خودتون کاستوم کنین، اما من چون روی سایت قبلیم که با استفاده از Hugo که یک Static Site Generator هست همه کارهام رو کرده بودم، راحت تر بودم و از قبل Github َAction رو آماده کرده بودم تصمیم گرفتم برگردم به سایت خودم.
یکی دیگه از دلایلش هم این بود که از اول روی سرورم Reverse proxy رو ست کرده بودم و certificate و اینا رو اوکی کرده بودم، برای سایت static هم چیز زیادی لازم نبود، خیلی سریع یه Nginx بالا اوردم که سایت رو Serve میکرد و Github Action هم که قبلا با FTP روی Direct Admin کار میکرد رو عوض کردم که رو سرور Sync کنه.
الان سایت بالاست، فقط متاسفانه شاید مجبور شین با VPN ای چیزی واردش بشین. نمیدونم چه داستانیه، با اینکه ssh و ping و اینا رو همه بدون vpn میزدم، خود سایت بالا نمیاد. شما هم اگر دوست داشتین تست کنین، شاید مشکل از جای دیگه ای باشه.
خلاصه چالش های جالبی داشتم، این وسطا امنیت سرور هم بالا بردم.

@ever_code

سی شارپ پر از فیچرهاییه که شاید بگیم خیلی تفاوت زیادی ایجاد نمیکنن، میشه گفت بیشتر Quality of Life هستن. توی C#14 کلمه کلیدی بنام field اضافه شده. کاربردش برای وقتی هست که توی Property میخوایم فقط یکی از set یا get رو تعریف کنیم. قبل از این فیچر، وقتی میخواستیم که get و set رو با بدنه تعریف کنیم باید حتما یه فیلد با دسترسی private تعریف میکردیم که به اصطلاح بهش میگفتیم Backing Field:

class Person
{
    private  string  _name; // Backing Field

    public string Name {
        get => _name;
        set => _name = value;
    }
}

کمی بعد تر در تاریخ سی شارپ، اومدن Auto Implemented Property ها رو اضافه کردن که ما خیلی ازش استفاده میکنیم:

class Person
{
    public string Name { get; set; }
}

در اصل خود کامپایلر این کد رو به کد قبلی تبدیل میکنه و برای ما get و set رو به همراه یه backing field میسازه. تا قبل از سی شارپ 14، ما دسترسی به backing field که کامپایلر بصورت اتوماتیک میساخت نداشتیم و اگر میخواستیم که فقط یکی از get یا set رو پیاده سازی کنیم مجبور بودیم تا backing field رو هم اضافه کنیم.
اما الان با استفاده از کلمه field میتونیم دقیقا همینکار رو انجام بدیم:

class Person
{
    public string Name { 
        get;
        set => field = string.IsNullOrEmpty(value) ? "Not Defined" : value;
    }
}

بنظرم ازون دسته فیچرهایی هست که خیلی زود بهش عادت میکنیم و بعدش توهم میزنیم که از روز اول توی زبان بوده 😂
این یکی از نکات جذاب سی شارپه بنظرم، خیلی از فیچرهایی که توی سال های اخیر اضافه شدن صرفا برای راحت تر کردن و خوانا تر کردن کد بودن، درحالیکه شاید تنها کاری که کردن این بوده که کد تکراری و boiler-plate رو توی کامپایلر اتوماسیون کردن.

@ever_code

هیچوقت فکر نمیکردم روزی بیاد که وبسایت داکیومنت دانلود کنم، تا الان دو سه تا دانلود کردم تا اگر نت قطع شد روی سیستمم هاست کنم و ازشون بتونم استفاده کنم.
برای مثال keycloak تو گیتهاب یه پروژه داره که فایل استاتیک بیلد شده‌ی پروژه‌ی داکیومنتش هست با حجم ۲.۵ گیگ و اگر دانلود کنین میتونین با پایتون با کامند زیر:

python -m http.server 8080

یا با npx با دستور زیر:

npx server index.html

روی لوکال هاست اجراش کنید.

@ever_code

متوجه شدم که minio به کل تعطیل شده و ایمیج های داکرش رو دیگه حتی maintain نمیکنن.
قبل از این اتفاق یکی از سرویس‌های خیلی خوب برای file storage همین minio بود که با Amazon S3 کار میکرد. بنظر میاد اخیرا از دنیای اوپن سورس فاصله گرفته، و تا مدتی میشد سورس رو گرفت و بیلد انجام داد و اورد روی داکر، اما اخیرا ریپازیتوری خودش رو هم آرشیو کرده.

در کمی گشت و گذار رسیدم به RustFS که یک جایگزین بشدت قوی هست و ۱۰۰ درصد S3 Compatible هست و توی دات نت میشه با پکیج Amazon.S3 باهاش کار کرد.
https://rustfs.com/

@ever_code

از open-spec و spec-kit خوشم نمیومد، حس میکنم توکن زیاد مصرف میکنه. اومدم مثلا ابتکار به خرج بدم خودم عملا کاراییش رو دستی تو Claude code تعریف کردم. بعد اینجوری بودم که خب همین شد که😭
حس میکنم به ورژن مدرن این برخوردم:

Take 3 days to automate a 20 mintue task

ولی در کل بد نشد تونستم روی پروژه کار کنم باهاش و rtk هم کمک کرد توکن کمتر مصرف کنه و حدودا هزار و خورده‌ای توکن کمتر مصرف کرد، اما مجبور شدم دات نت و همه چی رو روی WSL دوباره نصب کنم تا بیشترین، بهینگی رو بگیرم ازش. اما یجورایی با Spec-driven development حال میکنم.

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

@ever_code

آقا الان نگاه میکنم دو سال پیش این متن رو میذاشتن جلوم گیرپاژ میکردم مغزم اسکرین شات میگرفت، تکنولوژی واقعا عجیبه...

در راستای این پست بیاین چیزهای جذاب‌تری بهتون بگم!
این دوتا Library با زبان‌های Rust و C برای Front-end هستند:
Rust: https://github.com/dioxuslabs/dioxus
C: https://github.com/nicbarker/clay

اونی که با Rust نوشته شده، کاملا Cross-Platform  هست. اونی که با C هست یه کار جالبی که میکنه اینه که روی هر تغییر بجای اینکه مثل  React مثلا بیاد پوزیشن ها رو دستی بر اساس State تغییر بده و Component ها رو تکون بده، میاد کاملا صفحه رو از اول رندر میکنه! اول که اینو فهمیدم اینجوری بودم که خب اینکه خیلی بهینه نیست؟! اما واقعیت اینه که 1. زبانمون C هست! 2. کلی از دردسرهای State Management رو نداره. 3.کاربر واقعا متوجه نمیشه! 4.خیلی سایت‌ها با فریمورک‌های غول‌تری با JS/TS زده شدن که خیلی بدتر از این حرفان!

بنظر خودم خیلی جذابه که با این زبان‌ها وارد دنیای Front-end شد ( مشخصه خیلی با JS میانه خوبی ندارم یا بگم؟ )
شاید نوع کد زدن توشون خیلی فرق داشته باشه و خیلی‎ها نخوان که توی production ازشون استفاده کنن. اما چندتا نکته مهم هست که باید توجه بشه بهشون.
اکثر افراد دارای سوگیری تجاری زبان هستند. یعنی بطور پیش فرض وقتی میشنون دات نت ذهنشون میره سمت Back-end یا js  میشه برای Front-end یا C و Rust میشن برای کارهای Low-level. اما واقعیت اینه که با اینکه میدونیم NodeJS هست، یا مثلا دات نت MAUI داره، یا الان دیدیم که Rust فریمورک Front-end داره و C سال‌هاست که QT داره و بشدت توی صنعت ازش استفاده میشه، باز سوگیری داریم.
ما یادمون میره General Purpose Programming Language یعنی چی؟ اما چیزی که خیلی‌ها روش تاکید دارند اینه که توسعه دهنده نباید برده‌ی ابزار باشه، ابزار صرفا یک مسیر برای رسیدن به هدفه، همینطوری که Ai یک ابزاره.

@ever_code

از Microservice به Outsourced Microservice و سرویس‌های Domain-Agnostic

وسط جنگ، شروع کردم دوره‌ی Event sourcing دیدن. دید خیلی بهتری بهش پیدا کردم و یاد گرفتم که چطوری بصورت استاندارد ازش استفاده کنم و پیاده سازیش کنم.
اما چیزی که برام واضح تر بود، این نبود که خب این رو الان کجا پیاده‌سازی کنم. این بود که الان که میدونم چیه، و چقدر پیچیدگی الکی میتونه استفاده کنه، کجاها سراغش نباید برم.
هرچی بیشتر یاد میگیرم به این مفهوم نزدیک‌تر میشم که ساده نگاهش کن، مگر اینکه برخلافش نیاز باشه.
یکی از چیز‌هایی که در سال‌های اخیر خیلی سر و صدا کرد مایکروسرویس بود. مایکروسرویس واقعی، هزینه مالی و انسانی زیادی میبره. با گذشت زمان، به یک دید متفاوت رسیدم. درسته که کل سیستم رو مایکروسرویس دیدن الکی گنده هست و باید بررسی عمیقی برای انجام دادن یا ندادنش صورت بگیره. اما خیلی از سرویس‌ها رو دیگه نیاز نیست خودمون توسعه بدیم. بهش که فکر میکردم کلمه‌ی Outsourced Microservices مناسب بنظر میاد.
وقتی میتونیم سرویس احراز هویت رو با keycloak، سرویس سرچ رو با ElasticSearch، سرویس مدیریت فایل رو با Minio و نرم افزارهای مشابهش راه بندازیم، دیگه خیلی منطقی نیست که خودمون توسعه بدیم. اینجوری با یک سرویس مربوط به بیزنسمون، و چندتا سرویس آماده میتونیم به سرعت به یک سیستم شبیه مایکروسرویس برسیم.

ایده‌ی اصلی اینجا اینه که از سرویس‌های Domain-Agnostic استفاده کنیم. یعنی سرویس‌هایی که ربط مستقیمی به Domain ما ندارن. صرفا به ما کمک میکنن که تمرکزمون روی Domain باشه.

راجب این تجربه توی بلاگ بیشتر نوشتم:

https://mazdakparnian.com/blogs/2026-04/simple-choices

@ever_code