خب خب امسال هم به دسامبر رسیدیم و تمرین‌های 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