اینم اینجا باشه یادگاری از ردیت
@ever_code

اخیرا ردیت اومده یواش یواش بخش‌هایی از بک اند رو از پایتون به گولنگ تغییر داده. اولین سرویسی که تغییرش رسمی روی پروداکشن اومده سرویس کامنت هست. توی ردیت کامنت یه بخش خیلی بزرگی از کل پلتفرمه. برای همین خیلی مهمه که سیستمی که این بخش رو مدیریت میکنه برای throughout بالا مناسب باشه. بنظرم بحث جذابیه و ارزش خوندن داره.

لینک مقاله‌ش توی خود ردیت:
https://www.reddit.com/r/RedditEng/s/2tmpQVQSdv

#reddit #golang #systemdesign

@ever_code

خب خب امسال هم به دسامبر رسیدیم و تمرین‌های Advent Of Code. یک مجموعه مساله برنامه نویسی که ده سالی شده که هر سال از اول دسامبر تا ۲۵ دسامبر هر روز یکی منتشر می‌شن و می تونین به هر زبونی حلش کنین و برنامه نویسی خودتون (یا مهارتتون در یک زبون خاص) رو بهتر کنین. سطوح مساله‌ها متفاوت است و به شکل سنتی جلوتر که می‌ریم سختتر می شن. موضوعات جالبن و سوال‌ها هیجان انگیز طراحی شدن. و خب معلومه که خیلی هاش (احتمالا امسال همه) رو هوش مصنوعی می‌تونه حل کنه؛ دقیقا همونطور که لیفتراک می‌تونه کل وزنه‌هایی که توی جیم می‌زنین رو یه جا بلند کنه (: سوال اینه که شما می‌خواین وزنه‌ها رو جابجا کنین یا می خواین ورزیده بشین.

با ادونت آو کد امسال خوش بگذره. من معمولا تفننی هر روز نگاهش می کنم و گاهی سعی می کنم حلش کنم اگر در طول روز وقت داشته باشم.

https://adventofcode.com/2025/about

#برنامه‌_نویسی

ایونت advent of code 2025 شروع شد. منم شرکت کردم و یواش یواش جوابای سوالایی که حل میکنم رو توی این ریپازیتوری میذارم:
https://github.com/PureJoyMind/AdventOfCode2025
سعی کردم تمیز و خوانا و در عین حال با در نظر گرفتن پرفورمنس بنویسم و فقط جواب‌هایی رو قرار میدم که تائید شده باشن.
هدف اینه که خودمون رو به چالش بکشیم و اگر هم شد چیزی یاد بگیریم.
شماها هم شرکت کنین و راه حلاتون رو به اشتراک بزارین😍

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

@ever_code

به زیبا ترین و پرکتیکال ترین روش ممکن مباحث مجازی سازی نتورک در لینوکس رو توضیح داده
https://thachmpham.github.io/

همه‌ی دات‌نت‌کارها با Entity Framework و Repository Pattern آشنا هستن و احتمالاً اکثرمون با این بحث که آیا واقعاً نیاز به Repository داریم وقتی خود EF داره این کارو می‌کنه، درگیر شدیم. یکی از قوی‌ترین دلایلی که مخالف این پترن هست، اینه که خب ما توی پروژه‌های واقعی هیچ‌وقت نمیایم دیتابیس رو تغییر بدیم که Repository بخواد کمکمون کنه.
با اینکه این فرضیه برای اکثر پروژه‌ها درسته، اما مثال نقض هم داره. اکثر ما وقتی راجع‌به پروژه فکر می‌کنیم چیزی مثل فروشگاه توی ذهنمون میاد؛ مثل دیجی‌کالا، یا سایت‌های بانکی و مالی. و خب کاملاً درسته که توی اون‌جور پروژه‌ها نخوایم لایه‌ی دیتابیس رو تغییر بدیم. اما نرم‌افزار فقط شامل فروشگاه و حسابداری و بورس نمیشه. یه دسته از نرم‌افزارهایی هم هستند که برای اینکه توی سازمان استفاده بشن، یا تحت وب و برای عموم، باید خودمون روی سرورمون نصبشون کنیم. مثال فنی مثل Keycloak یا نرم‌افزارهای مدیریت مستندات سازمانی و بقیه‌ی نرم‌افزارهای زیرساختی، فنی و کاربردی درون‌سازمانی.
اینجور نرم‌افزارها معمولاً ، نه همیشه، به ما حق انتخاب بین چند دیتابیس رو میدن. اینجاست که استفاده از Repository و یا حتی خود EF خیلی به‌درد می‌خوره. علت اینکه همیشه ممکنه EF جوابگو نباشه هم اینه که شاید لایه‌ی داده‌مون الزاماً دیتابیس نباشه و شاید یه سرویس مجزا باشه که باید بهش HTTP Request بزنیم و داده رو بگیریم. پس باید فکر کنیم که کاربرد ما چی می‌تونه باشه و بر طبق اون پیش بریم. از اونجایی که این چند ماهه خیلی با نرم‌افزارهای این‌جوری درگیر بودم، این موضوع برام جالب بود که اگه خودم قرار باشه سیستمی طراحی کنم که چندتا دیتابیس مختلف رو بتونه ساپورت کنه، چیکار می‌کردم.

@ever_code

https://softwarepatternslexicon.com/

"Your ad-free encyclopedia of code-level patterns and real-world architectures. Master OOP & FP, microservices, EIP, DDD, streaming, ML patterns, and cloud-native design—then validate skills with Mastery™ Tech Exam Prep. "

این سایت یک دانشنامه برای Design pattern، Architecture و مطالب مرتبط هست. حجم مطالبش زیاده و بنظر جذاب میاد برای گشت و گذار، تحقیق و یادگیری.

@ever_code

استفاده از Guid مزایا و معایب خودش رو داره. دوتا نکته مهمی که راجبش وجود داره، یکی تفاوت سایزش با int هست، به این صورت که idهایی از جنس int توی دیتابیس 32 بیت فضا میگیرن، اما id هایی از جنس Guid توی دیتابیس 128 بیت فضا میگیرن. چالش بعدی، تصادفی بودنشون خوبه ازین جهت که یه سری پیچیدگی‌های رو کم میکنه و نیازی نیست خیلی نگران id تکراری باشیم، اما همین تصادفی بودن باعث میشه موقع index کردن دیتابیس به مشکلی تحت عنوان index fragmentation بر بخوریم. لینک زیر بیشتر راجب این موضوع توضیح میده:
https://www.mssqltips.com/sqlservertip/4331/sql-server-index-fragmentation-overview/
اما راه حل چیه؟ ما نیاز داریم تا بتونیم حداقل تا حدی از کاملا تصادفی بودن دور بشیم در حدی که بتونیم "تا حدودی" id های sortable داشته باشیم. مقاله‌ی زیر میاد این مسائل رو بطور مختصر بررسی میکنه و راه حل مناسبی ارائه میده:
https://andrewlock.net/generating-sortable-guids-using-newid/
راه حل چیه؟ پکیج NewId اومده و با الهام گرفتن از روشی که توئیتر روی Snowflake استفاده کرده برامون UUID یا همون GUID خودمون تو دات نت ایجاد میکنه که sortable هست. این کار چه اثری داشته؟
میزان fragmentation رو از 98 درصد به 5 درصد کاهش میده. داخل هر page دیتابیس فضای خالی کمتری بجا میزاره، اینطوری که guid عادی 75 درصد هر page رو پر میکنه اما guid جدیدمون 98 درصد رو پر میکنه و اینطوری باعث شده که تعداد page های ساخته شده از 77 تا به 59 تا برسه و از فضا بصورت بهینه استفاده کنه!

@ever_code

زبان Zig: زبانی که آروم داره جای خودش رو پیدا می‌کنه

این روزها هرجا نگاه می‌کنم، یه پروژه performance-critical جدید می‌بینم که با Zig نوشته شده. Bun - همون JavaScript runtimeی که هفته پیش Anthropic خریدش با Zig نوشته شده. Lightpanda - یه headless browser که ادعا می‌کنه ۱۰ برابر Chrome سریع‌تره با Zig نوشته شده. TigerBeetle - یه دیتابیس مالی که قراره جایگزین سیستم‌های بانکی بشه - با Zig نوشته شده.

مقاله Lightpanda یه تیتر خیلی صادقانه‌ داره: «چون به اندازه کافی باهوش نیستیم که با C++ یا Rust بنویسیم.»

زبان Zig رو Andrew Kelley از سال ۲۰۱۵ شروع کرد چون داشت روی یه پروژه real-time audio کار می‌کرد و از C کلافه شده بود. فلسفه طراحی‌ش ساده‌ست: هیچ چیز مخفی نباشه. هیچ hidden allocation نداری، هیچ operator overloadingی نداری، هیچ exceptionی نداری. وقتی کد رو می‌خونی، دقیقاً می‌فهمی چی اجرا میشه. یه فیچر خیلی قوی داره به اسم comptime که باهاش می‌تونی موقع کامپایل کد اجرا کنی - مثل macroهای C ولی با همون سینتکس Zig. همچنین می‌تونی مستقیم headerهای C رو import کنی و با کدبیس‌های قدیمی کار کنی.

حالا سوال اصلی: چرا Zig و نه Rust؟ جواب کوتاه: Zig ساده‌تره ولی unsafe تره. Rust با borrow checker تضمین می‌کنه memory safe هستی، ولی learning curve سنگینی داره. Zig این تضمین رو نمیده - بجاش یه سری runtime check داره که توی debug mode کمکت می‌کنه. Jarred Sumner (سازنده Bun) گفته اول می‌خواست با Rust بنویسه ولی نتونست productive باشه. تیم TigerBeetle هم گفته برنامه‌نویس‌های خوب از هر زبانی می‌تونن Zig رو توی یه آخر هفته یاد بگیرن.

زبان Zig هنوز به نسخه ۱.۰ نرسیده و اکوسیستم بالغی نداره. برای پروداکشن معمولی توصیه نمیشه. ولی برای systems programming - جایی که می‌خوای به سخت‌افزار نزدیک باشی، performance حیاتیه، و با زبان C باید interpolation داشته باشی - داره به یه گزینه جدی تبدیل میشه. وقتی Anthropic میاد Bun رو می‌خره و میگه می‌خوایم زیرساخت Claude Code رو باهاش بسازیم، یعنی این زبان دیگه فقط یه اسباب‌بازی نیست.

Why We Built Lightpanda in Zig
Because We're Not Smart Enough for C++ or Rust
https://lightpanda.io/blog/posts/why-we-built-lightpanda-in-zig

Anthropic acquires Bun as Claude Code reaches $1B milestone
https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone


@gocasts

شاید یکی از بزرگترین پشیمونی‌هام این باشه که به اندازه کافی تو دانشگاه توی low-level programming عمیق نشدم. الان باید انرژی بیشتری بزارم تا به چیزی که اون موقع زمانش رو راحت داشتم برسم.

@ever_code

از ۴ شنبه بگم گه خلاصه کل آخر هفته برنامه مفید کنسل بود😂😭
چشمام از کاسه درومد بدون عینک

آیا از پیاده سازی متدهای خودتون خسته شدین؟ خب مهم نیست بسپارینش به AI به ما چه اصلا😂
به
No-implementation oriented programming
سلام کنید😭

https://github.com/lofcz/ai

این دوستمون اومده پکیجی نوشته که میاد متدهایی که حال نداریم بنویسیم رو میسپره به AI و در زمان اجرا جوابشون رو میگیره ازش.
شوخی عجیبیه ولی خب...

@ever_code

https://youtu.be/tadUeiNe5-g?si=lPrCP24puDoMpOcm

یه ویدیوی نیمچه معماری کامپیوتری برای سر شب
@ever_code

توی Front-end ما اکثرا تصوری که داریم یا وب هست و یا اپلیکیشن برای گوشی یا کامپیوتر، همه‌ی اینها زیرمجموعه‌ی Graphical User Interface (GUI) یا رابط کاربری گرافیکی میشن. پس میشه پرسید که خب رابط کاربری غیر گرافیکی چی؟ اینجاست که با Terminal/Text User Interface (TUI) آشنا میشیم.
به شخصه خیلی ازش لذت میبرم و حتی بنظرم توسعه‌ش جذاب‌تره. شاید ساده بنظر بیاد اما خیلی کارهای حرفه‌ای و قشنگی میشه باهاش انجام داد.
بنظرم اگه روزی اپلیکیشنی برای پلتفرم‌های مختلف توسعه بدم، حتما نسخه‌ی ترمینالش هم سعی میکنم توسعه بدم.

توی دات نت برای توسعه‌ی اپلیکیشن ترمینالی یا کنسول، یکی دوتا پکیج معروف هست. یکیش Spectre.Console هست:

https://spectreconsole.net/

یکی دیگه‌ش هم Terminal.Gui هست که نسبت به قبلی کمی متفاوته و کارهای تخصصی تری شاید بشه باهاش انجام داد:

https://github.com/gui-cs/Terminal.Gui

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

در گشت و گذار بودم که به این پروژه‌ی جالب برخوردم:
https://github.com/andrewmd5/dawn
یک Terminal Live Markdown Editor هست. ظاهر باحالی داره اما احتمالا بدرد کسی بخوره که اکثر وقتش رو توی ترمینال میگذرونه. خلاصه از TUI غافل نشین!

@ever_code

توی این ویدئو سریع و سر راست در مورد تگ زدن در گیت حرف می‌زنیم. روشی است برای اینکه مثلا روی نرم افزارتون ورژن بزنین یا به گیت هاب بگین که اگر کسی اومد دانلود کنه فلان نسخه ها رو بذار توی بخش releaesها یا اگر خودتون خواستین به جایی از تاریخ برگردین، به راحتی با یه اسم بهش برسین.

https://youtu.be/jjaBdcgsz1A

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

@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