نوشته‌های ترمینالی

این مطلب رو سال ها پیش گذاشته بودم در مورد این که چطور با پروژه های سنگین برنامه نویسی، خودمون رو به چالش بکشیم و چیز جدید یاد بگیریم.
این مطلب قسمت دوم هم داره که لینکش رو در ادامه می‌گذارم. مورد علاقه مورد web browser متنیه. توضیحاتشو میتونید بخونید.

https://austinhenley.com/blog/morechallengingprojects.html

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

https://kind.engineering

در مورد معماری Hexagonal یا همون Port&Adaptor توی اپلیکیشن بک‌اندی، این بلاگ رو دیدم و خیلی خوب توضیح داده بود.

https://medium.com/fastned/the-hexagon-a-battle-tested-blueprint-for-your-event-driven-app-163d4e40bd2d

چرا سرعت ۱۰ برابری کدنویسی با AI ممکنه به یک تله‌ی بدهی فنی/ technical debt تبدیل بشه؟
چند وقت پیش ویدیوی Mario Zechner (سازنده‌ Pi coding agent) با عنوان «ساختن PI در دنیای Slop» رو دیدم و باید بگم که با نگاهش موافقم برای کسایی که با AI کد تولید می‌کنند. یک بلاگ راجع بهش نوشتم که لینکش را پایین میذارم.
این روزها صنعت بیش از حد درگیر «ایجنت های ماکسیمالیستی» شده؛ ابزارهای بیشتر، ساب‌ایجنت‌های بیشتر، مدیریت کانتکست پیچیده‌تر و کلی لایه‌ی اضافی. اما داده‌ها داستان متفاوتی را تعریف می‌کنند.
سه نکته‌ی مهمی که از صحبت‌های ماریو برداشت کردم:
۱- مینیمال بهتر از ماکسیمال است:
بنچمارک‌هایی مثل Terminal Bench نشان می‌دهند که ساده‌ترین محیط‌ها (اغلب فقط یک ترمینال) به‌طور مداوم از هارنس‌های پیچیده و پر از قابلیت عملکرد بهتری دارند.

ایجنت Pi هم دقیقاً همین فلسفه را دنبال می‌کند:
* فقط ۴ ابزار
* یک سیستم‌پرامپت بسیار کوچک
* بدون هیچ جادوی پنهانی برای هرس کردن کانتکست

نتیجه؟ سیگنال تمیزتر و کد بهتر.
۲- ایجنت‌ها درد را حس نمی‌کنند:
یک توسعه‌دهنده‌ی واقعی وقتی با یک کدبیس/codebase شلوغ و به‌هم‌ریخته روبه‌رو می‌شود، خسته و کلافه می‌شود و در نهایت سراغ ریفکتور می‌رود.

اما یک ایجنت هوش مصنوعی بدون هیچ مشکلی ممکن است ۱۰ هزار خط کدی تولید کند که از نظر محلی «درست» هستند (locally correct)، ولی از نظر معماری یک فاجعه‌ی کامل محسوب می‌شوند.
هوش مصنوعی فشار و هزینه‌ی بدهی فنی را حس نمی‌کند؛ تا زمانی که کدبیس آن‌قدر بزرگ میشه که حتی خود مدل LLM هم دیگر نتواند آن را درست درک کند.
۳- اصطکاک همیشه دشمن نیست:
سال‌ها به ما گفته‌اند که هر نوع اصطکاک در فرآیند توسعه بد است و باید حذف شود.
اما ماریو نظرش متفاوته:
"اصطکاک همان چیزی است که باعث می‌شود درک و دانش از کد به ذهن شما منتقل شود."
اگر تمام این اصطکاک را با ایجنت‌ها حذف کنید، کم‌کم دیگر توسعه‌دهنده نخواهید بود؛ بلکه تبدیل می‌شوید به کسی که فقط کدی را بازبینی می‌کند که خودش واقعاً آن را نمی‌فهمد.

استراتژی پیشنهادی برای ۲۰۲۶:
- وظایف را تا حد ممکن کوچک و مشخص تعریف کنید.
- به‌شدت روی ماژولار بودن سیستم پافشاری کنید.
- از ایجنت‌ها برای کارهای خسته‌کننده مثل تولید boilerplate یا بازتولید باگ‌ها استفاده کنید.
- خطوط مهم و حساس کد را خودتان بخوانید. تک‌تک‌شان را!!!

در نهایت، هوش مصنوعی یک ابزار دقیق و قدرتمند است، نه جایگزینی برای تفکر معماری و قضاوت مهندسی.

اگر دوست دارید بلاگ کامل من با عنوان «Slop, Speed, and Discipline: Hard Truths About AI Coding Agents» را بخوانید، می‌توانید اینجا بخونیدش.
Blog: https://mlnotes.substack.com/p/slop-speed-and-discipline-hard-truths

@DevTwitter | <Mehdi Allahyari/>

زمانی که یه تیم دیگه به تغییر در کد ما نیاز داره، سه تا گزینه داریم، کدوم یکی بهتره:
۱- بهشون بگیم خودشون تغییر رو انجام بدن.
۲- بهشون بگیم ما کمکشون میکنیم ولی با خیلی تاخیر این کارو انجام بدیم.
۳- کار خودمون رو رها کنیم و کار اونجا رو انجام بدیم.

این مطلب میگه عموما گزینه دوم رو انتخاب می‌کنیم ولی گزینه سه بهتره. چون:
If you choose to finish your own task:
Your team will make it on time. The other team will be late, and will probably mention your team as the reason…

You choose to help the other team:
You will be late. The other team will be on time - and for sure they’ll mention your team saved them.


البته در نظر داشته باشید که این که به اینجا رسیدیم اصلا نشونه یک‌سری اشتباه بوده و باید کاری کنیم مشکلات اینچنینی به وجود نیان.

https://open.substack.com/pub/zaidesanton/p/the-delayed-opinions-givers-engineering


@terminal_stuff

‏زیاد دیدم که می‌پرسن چرا نوتیفیکیشن اپ‌ها از بله و ایتا گرفته تا تلگرام، توییتر و بقیه این روزها یا نمیاد.

واقعیت اینه که نوتیفیکیشن فقط به خود اپ مربوط نیست.

روی اندروید تقریباً همه Push Notificationها از طریق سرویس FCM گوگل ارسال میشن و روی آیفون هم از طریق سرویس APNs اپل.
(هواوی یا شیائومی یا ... سرویس مخصوص خودشون رو دارن)

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

وقتی اینترنت بین‌الملل یا دسترسی به این سرویس‌ها مختل می‌شود، نتیجه‌اش این می‌شود که:

ناتیف ها اصلاً نمی‌رسند

سازوکارش هم خیلی ساده است:

۱- اپ روی گوشی نصب می‌شود
۲- از گوگل/اپل یک شناسه دریافت می‌کند
۳- سرور اپ(مثلا بله یا تلگرام یا ...) پیام را به سرویس گوگل یا اپل می‌فرستد
۴- آن سرویس نوتیفیکیشن را به گوشی تحویل می‌دهد

برای همین اگر ارتباط با FCM گوگل یا APNs اپل مشکل داشته باشد، عملاً سیستم نوتیفیکیشن موبایل دچار اختلال می‌شود.

نکته مهم اینکه:
اپ نمی‌ره مستقیم به هواووی یا شیائومی یا گوگل و اپل API بزنه

فقط از SDK استفاده می‌کنه
بعد SDK می‌ره با سرویس مناسب حرف می‌زنه

FCM = Firebase Cloud Messaging

APNs = Apple Push Notification service

پ.ن: امیدوارم تونسته باشم ساده توضیح داده باشم. تو این روزا که ناتیف های بله و ... نمیاد مشکل از بله نیست ، اقایان سرویس های پوش ناتیف رو در دسترس قرار ندادن.

@DevTwitter | <iSegar0/>

آیا AI جامون رو به عنوان برنامه‌نویس میگیره؟

https://youtu.be/NZa5lApeFic

یه بحثی شکل گرفته در مورد اینکه آیا از روی آیدی auto increment می‌شونه فهمید یه سایتی چقدر کاربر داره. این دغدغه امنیتی درستیه و یه سری راه‌حل هم داره.
در واقع این روش‌ها اینطوری کار می‌کنن که آیدی عددی دیتابیس رو سمت سرور نگه می‌دارن و به کاربر نشون نمی‌دن؛ پس چیزی که به کاربر می‌دیم یه استرینگ یا عدد دیگه‌ست و انتظار می‌ره ما با سرعت مناسب بتونیم سمت سرور آیدی‌ای که کاربر داره رو به آیدی دیتابیس تبدیل کنیم.

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

NanoID
مثل UUID ولی کوتاه‌تره و با الفبایی که شما می‌گید می‌تونه کار کنه، بنابراین می‌تونه URL safe هم باشه (پیش‌فرض هست).

SnowflakeID
یه آیدی عددی که از ترکیب تایم‌استمپ، نود و شماره ماشین تولید می‌شه، بنابراین عملاً هم می‌تونه یونیک باشه هم ترتیبی نیست. چون عددیه و رقم‌های چپش بر اساس عدد زیاد می‌شن، در واقع صعودی هست و دیتابیس رو کمتر اذیت می‌کنه.

HashID
این روش آیدی رو به یه استرینگ رمزنگاری می‌کنه و سمت سرور قابل برگردوندن هم هست.

ایده‌های دیگه هم می‌شه زد، مثلاً hash کردن آیدی به همراه salt، ولی به نظرم مزیت خاصی ایجاد نمی‌کنه نسبت به UUID.

چرا squash کردن کامیت ها بد است.

این مطلب توضیح میده که squash در عمل فقط منجر میشه یکسری کامیت تاریخی رو از دست بدیم در حالی که میتونیم نگهشون داریم و صرفا بهشون نگاه نکنیم با تغییر کامندهامون.
مهم ترین دلیل هم اینه که:
Git tracks contents, not diffs.In many ways you can just see git as a filesystem.


https://dev.to/wesen/squash-commits-considered-harmful-ob1

من این ویدیو رو دوست داشتم. با یکی از Engineering Managerهای قدیمی گوگل یه مصاحبه سیستم‌دیزاین نمونه برگزار می‌کنن. سوالش هم طراحی Spotifyئه. البته چون مدت ویدیو کوتاهه (۴۰ دقیقه) جزئیاتش خیلی کمه ولی همچنان میشه خیلی ازش یاد گرفت.
https://www.youtube.com/watch?v=_K-eupuDVEc

اگه دوست دارید با انجام دادن پروژه، چیزها رو یاد بگیرید این ریپوی awesome برای شماست.
برای هر موضوعی کتاب و بلاک پست های مرتبط رو جمع‌اوری کرده. مثلا تو قسمت پایتون میتونید آموزش ساخت گیت با پایتون رو پیدا کنید.


https://github.com/practical-tutorials/project-based-learning

استفاده از AI در فرایند استخدام مثلا در cover letter باعث شده پیدا کردن کاندید های خوب سخت تر بشه. پس به عنوان مهندس چیکار کنیم؟ روی چیزهایی تمرکز کنیم که قابل جعل با AI نیست، مثلا این که «در جای قبلی که بودی چیکار کردی؟»
https://leaddev.com/hiring/cover-letters-used-to-mean-something

چرا تیم برنامه نویسی کند عمل می‌کنه؟ به دلایل مختلف،ولی معمولا هیچ کدوم «برنامه نویس تنبلی می‌کنه» نیست.

https://medium.com/javascript-scene/why-development-teams-are-slow-89107985c75c

من این مطلبو خیلی دوست داشتم و به نظرم خیلی دید خوبی میده از اینکه چرا شرکت ما تندتر یا کندتر از یه شرکت دیگه حرکت می‌کنه.
طرف میاد مقایسه می‌کنه که برنامه نویسی تو یک شرکت اینترپرایز چطوریه و با یک شرکتی که محصول داره مثل متا مقایسه‌ش می‌کنه.
دسته‌بندیش رو خیلی قبول ندارم ولی به نظرم دو سر طیفو خیلی خوب مشخص می‌کنه. نظر من اینه که شرکت محصولی هم می‌تونه کند حرکت کنه بسته به چیزی که ارائه میده یا برای یه سری تغییر ها فرایندهای پیچیده داشته باشه.

https://thehustlingengineer.substack.com/p/software-engineering-in-enterprise

Behind "Hello World" on Linux
https://jvns.ca/blog/2023/08/03/behind--hello-world/

قصه پر غصه Caching در DBMSها: PostgreSQL

فکر میکنم بر همگان واضح و مبرهنه که چرا caching به کرّات تقریبا همه‌جا (از کش چندلایه‌ای که در سطح پروسه‌ست بگیر تا کشی که سیستم‌عامل در سطح دیسک استفاده میکنه) استفاده میشه. علت یک خطیش میشه این که تا گپ زمانی که بین حافظه‌های مختلف در سرعت دسترسی به اطلاعات وجود داره رو تا حد امکان برای ما خفیف‌تر کنه. با این تفاسیر، بهره بردن از مکانیزم های Caching در DMBS ها چندان هم دور از ذهن نمیرسه. اما ماجرا به این سادگی ها که بنظر میاد نیست. بهتر بگم، ماجرا کاملا پیچیده است!
وقتی صحبت از کش میشه، یک پای ماجرا همزمانیه، یک پای دیگه Data Inconsistency و طبعاً هم بحث مدیریت حافظه و ده‌ها غصه دیگه. امروز داشتم از سر کنجکاوی نگاهی به فصل ‌Buffer cache and WAL کتاب Postgresql internals مینداختم تا یک کمی سر در بیارم که چطوری این ماجرا اتفاق میفته. همونطور که انتظارشو داشتم، کتاب به تفضیل این مبحث رو شرح داده و حتی به سورس کد هر بخشی هم که راجع‌بهش صحبت میکرد (مثلا Hash tableای که برای نگهداری buffer ID ها از اون استفاده شده)، به سورس کد اون ارجاع داده (هرچند که متاسفانه توضیحی روی پیاده سازی نداده). واقعیت امر اینه که فهمیدن سورسش از سواد من خارج بود ولی خوندن و مطلع شدن راجع‌به مکانیزم ماجرا، من رو سر ذوق آورد و برای همین خواستم تا اون رو اینجا با شما به اشتراک بذارم.

توصیه میکنم قبل این که وارد کتاب بشید، اول به این مقاله که Caching و Buffer Cache رو در PostgreSQL توضیح داده رجوع کنین:
https://postgrespro.com/blog/pgsql/5967951

مقاله در اصل همون مطالب کتابه ولی کمی ساده‌تر و کمی قابل فهم تر. در قدم بعدی هم خود کتاب که لینکش رو بالاتر گذاشتم. من هم اگر فرصتی باشه تلاشم رو میکنم اون چیزی که از این ماجرا متوجه شدم کمی ساده‌تر اینجا بنویسم. عجالتاً این رو از من بپذیرید تا بعد که ببینم چی میشه.
———
پ.ن:
مشابه این کار رو قبلا تو این پست راجع‌به Query Planner انجام دادم. اون چه که خوندم و متوجه شدم رو سعی کردم کمی ساده‌تر توضیح بدم. فکر میکنم مرورش چندان خالی از لطف نباشه.

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

https://yager.io/programming/go.html

البته مطلب یکم قدیمیه، برای قبل از معرفی generic به گو.

دوستان با توجه به وضعیت موجود شاید وقت خوبی باشه که lmstudio یا Ollama رو راه بندازید روی سیستم.

ماجرا اینه که یه نرم افزار نصب می‌کنید مثل lmstudio و توی اون مدل های هوش مصنوعی رو می‌تونید دانلود کنید بسته به مشخصات سیستم‌تون و بدون اینترنت بهشون دسترسی داشته باشید و چت کنید. lmstudio حالت گرافیکی داره و با خودش می‌شه چت کرد ولی api مطابق openai هم می‌ده و ollama حالت cli داره.

من روی یه لپتاپ با کارت گرافیک ضعیف موفق شدم qwen 3 VL و Ministral 3 رو اجرا کنم (هردو ۴ میلیارد پارامتری که حداقل اندازه بود) و با سرعت خیلی خوبی پاسخ دادن (۲۰ توکن بر ثانیه). البته اگه کلا کارت گرافیک ندارید سرعت پایین تره شاید در حد ۱-۲ توکن بر ثانیه.

توانایی‌شون توی کارهای مختلف متفاوته برای همین من ۲-۳ تا مدل ۳-۴ گیگی دانلود کردم و برای پرامت‌های متفاوت همه رو امتحان می‌کنم مثلا متن فارسی روی qwen خیلی جالب جواب نداد ولی Ministral خوب بود. اگه دنبال مدل‌های خوب بودین deepseek و glm و gemma هم مدل‌های خوب opensourceی هستن. خود lmstudio هم یه قسمت editor pick داره که بر اساس رم سیستم مدلهای خوب رو پیشنهاد می‌ده. داخل صفحه مدل که برید میگه که این مدل می‌‌تونه کامل بره روی gpu یا partial بره یا اصلا خیلی بزرگه و احتمالا اجرا نمی‌شه.


مطالب قبلی در این باره:
https://t.me/terminal_stuff/2902
https://t.me/terminal_stuff/2903

شما هم تجربه‌تون رو به اشتراک بگذارید.

چرا وایب کدینگ باعث از بین رفتن اکثر پروژه های open source میشه؟

https://hackaday.com/2026/02/02/how-vibe-coding-is-killing-open-source/

چرا لاگ زدن به شکلی که معمولا استفاده می‌شه بده و بهتره رویکردمون رو عوض کنیم.

روش که این سایت پیشنهاد می‌ده، Wide logهستش. ایده‌ی کلیش اینه که به ازای هر درخواست کاربر یه لاگ داشته باشید که در اون تمام اطلاعات لازم وجود داشته باشه. از اطلاعات ساده مثل متد ریکوئست http تا اطلاعات با cardinality بالاتر مثل user_id

همچنین میگه که strucured logging و open telemetry اگرچه که خوب هستن ولی ابزار و استاندارد هستن ولی چیزی که ما می‌خوایم روحیه مناسبه.

روشی که برای پیاده‌سازیش هم توی سمپل‌کدها پیشنهاد می‌ده اینه که در طی روند پردازش درخواست اطلاعات لازم رو توی یه آبجکت event نگه داریم و به همه‌ی تابع‌ها پاسش بدیم، در نهایت وقتی کارمون انجام شد توی یه Middleware چاپش کنیم. (من البته خیلی با این روش موافق نیستم چون خطای انسانیش زیاده در فلوهای مختلف و اونطوری ما هیچ لاگی نداریم)

برای کاهش تعداد لاگ هم sample کردن رو پیشنهاد میده. با یه سری شرط مثل این که کاربرای داخلی و مهم (مثل QAها) و جاهایی که خطا داشتیم یا کند بودیم به همراه یه درصد کمی از درخواست‌های عادی.

https://loggingsucks.com/