در این شرایط بازار ایران، شاید تمرکز روی توسعه فردی برای بعضیا سخت باشه و حق دارن. اما نباید آدم خودش رو ببازه و یا بهانه کنه. دلار فردا تا ۴۰۰ بره، پس فردا بیاد روی ۵۰، با اینکه وضعیت جیب ما شاید خیلی تغییر کنه، ولی حقیقت امر اینه که نمیشه با تصمیم‌های احساسی کاری براش کرد. تهش وقتمون هدر رفته. توی این شرایط با افزایش دانش اقتصادی‌مون، مدیریت سرمایه‌مون (حتی اگر سرمایه‌ای نداشته باشیم و یا احساس کنیم که انقدر کمه که چیزی نیست مدیریت کنیم) و فکر کردن به آینده، شاید بتونیم برای خودمون احساس بهتری، چه بسا موقت، ایجاد کنیم. من یکی به شخصه همیشه این حس رو داشتم که توی مدیریت سرمایه هیچی بلد نیستم و نمیدونم از کجا شروع کنم. اما برای شروع، کتابی که به من کمی کمک کرد و یه کوچولو دیدم رو بازتر کرد "هل اول" از صادق الحسینی بود. باعث شد بجای اینکه جلوی پام رو ببینم و کوچک بودن مبلغ سرمایه گزاری الانم، دراز مدت رو ببینم و تجمیعش + سود رو درک کنم. اینطوری حداقل کمی نوسانات هیجانی بازار آشفته ایران کمتر با روانم بازی میکنه، هرچند که اقتصاد مریض و ناسالمی داریم و قرار نیست خودمون رو گول بزنیم.
موفق و پیروز باشید❤️

@ever_code

در رابطه با TUI
https://youtu.be/d2ozTo24UZc
@ever_code

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

میخوام از دو نفر اینجا تشکر کنم که توی ریپو به صورت اوپن سورس مشارکت کردن و خیلی نظرات خوبی دادن و کلی روی کد وقت گذاشتن.

مزدک و یاسمین عزیز که دمشون گرم

خلاصه خوشحال میشم شما هم اگر فیچر خاصی یا بهبودی توی ذهنتون هست واسم PR بفرستین یا یک issue باز کنین.

اینم لینک ریپو اگر ندیدین و استار ندادین🙌

https://github.com/ashkanRmk/FastCrud

حال خوب شبانه😍

تا حالا شده بخواین یه API برای Get کردن یه مدل بزنین؟ مثلا برای گرفتن محصولات یه فروشگاه. توی اینجور سرویس‌ها معمولا با یه سری نیازمندی‌ها روبرو میشیم. برای مثال:
- نیاز داریم تا بتونیم مشخص کنیم چه فیلدهایی از مدل رو برگردونیم، یعنی مثلا توی درخواستمون بگیم فقط نام و کد ملی کاربر برگرده
- نیاز به pagination داشته باشیم
- نیاز به sort داریم
بصورت کلی تر بخوایم بگیم، وقتی نیاز داریم سرویسمون عملا برابر دسترسی Read برای یه Table توی دیتابیس باشه.
یه راه اینه که خودمون همه چی رو پیاده سازی کنیم، اما راه دیگه‌ای هم هست. میتونیم از پروتوکل OData (OpenData) استفاده کنیم.
یک پروتوکل برمبنای REST که قواعد مشخصی رو برای کوئری کردن دیتا تعریف میکنه. برای مثال برای گرفتن یوزر، طوری که نیاز داریم فقط یه سری ستون خاص رو بگیریم، یه Sort بزنیم روش، و فیلتر کنیم کوئری‌مون یه همچین چیزی میشه:
GET /odata/Users?$select=id,displayName,email&$filter=status eq 'active' and age ge 18&$orderby=displayName asc&$top=50&$skip=0
البته به کوئری ختم نمیشه و کلی کارهای دیگه میشه توی Body درخواست انجام داد.
میتونید اینجا کمی بیشتر راجبش بخونید:
https://www.odata.org/getting-started/basic-tutorial/

حالا چجوری توی دات نت یه سرور OData راه بندازیم؟
* پروژه رو با استفاده از EFCore به دیتابیس وصل میکنیم.
* پکیج Microsoft.AspNetCore.OData رو نصب میکنیم
* توی Program.cs ستاپ میکنیم:

c#
var modelBuilder = new ODataConventionModelBuilder();
modelBuilder.EntitySet<User>("Users");

builder.Services.AddControllers()
    .AddOData(options => options.Select().Filter().OrderBy().Expand().Count().SetMaxTop(100)
        .AddRouteComponents("odata", modelBuilder.GetEdmModel()));

* کنترلرمون رو بجای ControllerBase با ODataController میسازیم و برای هر مدلی که میخوایم OData براش داشته باشیم دوتا متد Get یکی برای همه رکوردها و یکی برای گرفتن با Id میسازیم:

c#
public class UsersController(ApplicationDbContext context) : ODataController
{
    
    [EnableQuery]
    public IActionResult Get()
    {
        return Ok(context.Users.OrderByDescending(o => o.CreatedOn));
    }
    
    [EnableQuery]
    public IActionResult Get([FromRoute] Guid key)
    {
        var saga = context.Users.FirstOrDefault(s => s.Id == key);
        return saga == null ? NotFound() : Ok(saga);
    }
    
}

اگر دقت کنید، وقتی که با DbContext داریم کاربرها رو برمیگردونیم، متد ToList رو صدا نزدیم. نمیخوایم که کوئری رو انجام بدیم، اون قسمت رو پکیج OData انجام میده برامون.
بعد این مراحل سرور OData آماده‌ست و میتونین هرنوع کوئری که نیاز دارین رو روی اون دیتا انجام بدین، pagination داشته باشین، sort کنین و خیلی بیشتر.

@ever_code

✨ 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 آوردمش بالا