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

مطلب دو قسمتی: چطور AI روی مهندیس نرم‌افزار تاثیر گذاشته. این مطلب جمع‌بندی یه نظرسنجیه که گروه the pragmatic engineer که من خیلی قبولشون دارم انجام داده. قسمت اول: https://newsletter.pragmaticengineer.com/p/the-impact-of-ai-on-software-engineers-2026 قسمت دوم: https://newsletter.pragmaticengineer.com/p/ai-impact-on-software-engineers-part-2 من نکات کلیدی‌ای که توی گزارش دیدم با تجربه‌ی خودم هم شخصی هم در شرکت مشابهت زیادی داشت.

من چطور از claude code استفاده می‌کنم؟ مهم ترین قاعده‌ای که رعایت میکنه اینه که مرحله برنامه‌ریزی و تایید گرفتنش از انجام دادن جداست. never let Claude write code until you’ve reviewed and approved a written plan نکته جالب دیگه اینه که از یه سری md استفاده می‌کنه که توش نتیجه research از وضعیت فعلی و کاری که میخوایم بکنیم رو داشته باشه. به قول خودش shared mutable state. مزیتش اینه که فایله رو خود شخص هم می‌تونه ببینه و تغییر بده به جای این که توی کانتکستش باشه. به همین دلیل هم Plan mode داخلی claude رو دوست نداره. در یک جمله بخوایم خلاصه کنیم: Read deeply, write a plan, annotate the plan until it’s right, then let Claude execute the whole thing without stopping, checking types along the way. https://boristane.com/blog/how-i-use-claude-code/

یه ایجنت تحت ترمینال بهتون معرفی می‌کنم به اسم oh my pi یا همون omp یکسری تصال به lsp و toolها داره و بهش دستور (!) میدید و میره با LLMکال های متفاوت،میسر راه می‌چینه و کار رو انجام میده. https://github.com/can1357/oh-my-pi با تشکر از @blk_st8 بابت معرفی.

همیشه موقع دانلود از AUR دقت کنید به PKGBUILD، این روزها بیشتر. https://archlinux.org/news/active-aur-malicious-packages-incident/

Yazi might be the fastest terminal file manager you’ll ever use. 🚀 https://itsfoss.com/yazi/

یکی از دوره‌های AI که واسه شرکت پاس می‌کردم (و مدرسش استاد استنفورد بود، خوش به حالش) می‌گفت شما می‌تونید هوش‌مصنوعی مسائل soft constraint رو حل کنید. وقتی که برای حل سوالتون ۱۰۰ تا راه‌حل وجود داره و شما با ۹۹ تاشون خوشحال و راضی میشین. و به مساله اون‌قدر تسلط دارین که اون ۱ راه‌حل غیر‌قابل‌قبول رو تشخیص بدین و استفاده‌ش نکنین. مثلا شما می‌خواین یه پاورپوینت درست کنین واسه یه ارائه کلاسی. خیلی به فرمت و استایل و انیمیشنا اهمیت نمی‌دین. چیزی هم اشتباه باشه می‌گیرین دستی درستش می‌کنین. در نقطه مقابلش مسائل hard constraint هستن که راه‌حلشون فقط و فقط به یک شکل و یک فرمت قابل قبوله، و اگر اون خروجی دقیقا از اون فرمت پیروی نکنه باید ریختش دور. مثلا شما همیشه می‌خواین اسم و فامیل و تاریخ تولد یکی رو بگیرین و تو یه چیزی ضرب و تقسیمش کنین، تبدیلش کنین به یه کلمه رندوم ۱۰ حرفی. و اگه خروجیتون ۹ حرفی باشه سیستمتون منفجر می‌شه و آدما پرتاب می‌شن به لایه سوم اتمسفر. در این زمینه‌ها توصیه می‌شود که خیلی به خروجی هوش‌مصنوعی دل نبندید، یا یک موجودیت مجزا رو در جریان قرار بدید که خروجی قراره دقیقا چه ریختی باشه، و با چماق بکاریدش بالاسر هوش‌مصنوعی تا اگر دست از پا خطا کرد حسابش رو برسه.

در مورد لامپ های لاوا روی دیوار دفتر کلادفلیر قبلا هم مطلب داشتیم. در این زمینه ویدیوی زیر هم جالبه. توضیح میده چرا کامپیوترها او تولید عدد رندوم بد هستن و چیکار ها می‌شه کرد و فیلمبرداری از لامپ های لاوا چطور کمک می‌کنه به امنیت بیشتر اینترنت. https://youtu.be/1cUUfMeOijg

سیستم دیزاین یک سیستم مالی: تا کجا transaction های دیتابیس جواب میده و وقتی جواب نمی‌ده باید چیکار کرد؟ رفت سراغ distributed transaction ویدیو کوتاهیه و ارزش دیدن داره. https://youtu.be/8ByEyCd-MEM?is=ew5bBr57KmAeOsl3

در مورد استفاده از ai برای جونیور ها این مطلب رو دوست داشتم به طور خلاصه میاد میگه ما توقع کار خوب و سریع از جونیور نداریم، بلکه داریم سرمایه‌گذاری می‌کنیم برای آینده، برای همین استفاده از ai براشون ایده خوبی نیست چون اجازه نمیده اون تجربه لازم رو کسب کنن. https://www.cohorte.co/letters/why-i-banned-ai-for-my-juniors-for-6-months

یه ویدیو خوب از یوتوبر ضد AI مورد علاقه‌م: برنامه‌نویس‌های گوگل چطوری از AI استفاده می‌کنن. خلاصه: مثل جاهای دیگه، بلکه کمتر، چون از ابزارهای اوپن سورس و بیرونی استفاده نمی‌کنن. https://www.youtube.com/watch?v=PbsocBPkoUc

توی سیستم‌های توزیع‌شده، هماهنگ نگه داشتن داده‌ها بین نودهای مختلف همیشه یکی از چالش‌های مهم و البته جذاب بوده. مخصوصاً وقتی چند نود به‌صورت هم‌زمان امکان Write داشته باشن و انتظار بره داده‌ها در نهایت روی همه نودها به وضعیت یکسانی برسن. یکی از رویکردهای قابل استفاده برای حل این مسئله، پیاده‌سازی Replication در لایه Application و بر بستر Event Streaming هست. در چنین معماری‌ای، تغییرات داده به‌جای اینکه مستقیماً از طریق مکانیزم‌های Replication دیتابیس منتقل بشن، به‌صورت Event منتشر و توسط سایر نودها مصرف می‌شن. برای این کار، می‌شه تغییرات دیتابیس شامل Add, Update و Soft Delete رو در لحظه Commit شناسایی کرد و از طریق الگوی Outbox برای انتشار آماده کرد. از سمت مقابل نیز Consumerهایی مسئول دریافت این رویدادها، اعمال مکانیزم‌های Idempotency و مدیریت خطاها از طریق DLQ خواهند بود تا تغییرات در مقصد به‌صورت قابل اعتماد اعمال بشن. در سناریوهای Multi-Master این‌چنینی، اولین چالش جدی معمولاً مدیریت Conflict داده‌هاست. زمانی که چند نود به‌طور مستقل روی یک رکورد تغییر ایجاد می‌کنن، باید مکانیزمی برای تعیین نسخه نهایی وجود داشته باشه. یکی از ساده‌ترین و در عین حال رایج‌ترین راهکارها، Last-Write-Wins (LWW) هست که در آن آخرین تغییر ثبت‌شده بر اساس زمان وقوع، به‌عنوان نسخه معتبر در نظر گرفته می‌شه. چالش مهم بعدی به شناسه‌های داده برمی‌گرده. در معماری‌هایی که چند نود به‌صورت مستقل داده تولید می‌کنن، استفاده از Primary Keyهای Auto-Increment معمولاً به تداخل منجر می‌شه. به همین دلیل استفاده از شناسه‌های Globally Unique اهمیت پیدا می‌کنه. GUID v7 یکی از گزینه‌های جذاب برای این سناریوهاست؛ چون علاوه بر یکتا بودن، به دلیل داشتن Timestamp داخلی، قابلیت Sort شدن داره و نسبت به GUIDهای سنتی رفتار بهتری از نظر ایندکس‌گذاری ارائه می‌کنه. ممکنه این سؤال مطرح بشه که چرا به‌جای چنین رویکردی از Replication نیتیو دیتابیس استفاده نشه؟ پاسخ اینه که در بسیاری از موارد، مسئله صرفاً انتقال داده بین چند دیتابیس مشابه نیست. گاهی نیاز داریم کانفلیکت‌ها در لایه Application مدیریت بشن، داده‌ها قبل از اعمال شدن دچار Transformation بشن یا حتی نودها از تکنولوژی‌های ذخیره‌سازی متفاوتی استفاده کنن. مزیت دیگه‌ی این رویکرد، وجود یک Log پایدار از تمام تغییرات سیستم هست. با استفاده از Kafka، رویدادها برای مدت مشخصی نگهداری می‌شن و هر Consumer می‌تونه مستقل از سایر اجزا وضعیت خودش رو بازیابی کنه. در نتیجه اگر نودی برای مدت طولانی از دسترس خارج بشه، پس از بازگشت می‌تونه از آخرین Offset پردازش‌شده ادامه بده و خودش رو با وضعیت فعلی سیستم همگام کنه. از طرفی، Eventهایی که برای Replication تولید می‌شن معمولاً کاربردشون به همینجا محدود نمی‌مونه. همون جریان رویداد می‌تونه توسط سرویس‌های دیگه برای Cache Invalidation، Analytics، Audit Logging، Search Indexing یا انواع پردازش‌های جانبی مصرف بشه. به همین دلیل، مکانیزم همگام‌سازی عملاً به بخشی از زیرساخت Event-Driven کل سیستم تبدیل می‌شه. پیاده‌سازی چنین معماری‌ای قطعاً بدون هزینه نیست و پذیرش Eventual Consistency هم چالش‌های خودش رو به همراه داره. اما در ازای این پیچیدگی، سیستمی به دست میاد که نودها می‌تونن مستقل عمل کنن، کانفلیکت‌ها به‌صورت کنترل‌شده مدیریت بشن و همگام‌سازی داده‌ها بدون وابستگی مستقیم به نوع دیتابیس یا ساختار استقرار انجام بشه.

این مطلب رو سال ها پیش گذاشته بودم در مورد این که چطور با پروژه های سنگین برنامه نویسی، خودمون رو به چالش بکشیم و چیز جدید یاد بگیریم. این مطلب قسمت دوم هم داره که لینکش رو در ادامه می‌گذارم. مورد علاقه مورد 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/>

این چنل آرشیو کتاب‌ها، برگه تقلب، پادکست و وبینار برای دولپرهاست، بدردتون میخوره. t.me/+M4QujCyYc9E1N2Rk عضوگیری محدوده رکوئست ها فردا اکسپت میشه...❤️

زمانی که یه تیم دیگه به تغییر در کد ما نیاز داره، سه تا گزینه داریم، کدوم یکی بهتره: ۱- بهشون بگیم خودشون تغییر رو انجام بدن. ۲- بهشون بگیم ما کمکشون میکنیم ولی با خیلی تاخیر این کارو انجام بدیم. ۳- کار خودمون رو رها کنیم و کار اونجا رو انجام بدیم. این مطلب میگه عموما گزینه دوم رو انتخاب می‌کنیم ولی گزینه سه بهتره. چون: 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 #زماندار

‏زیاد دیدم که می‌پرسن چرا نوتیفیکیشن اپ‌ها از بله و ایتا گرفته تا تلگرام، توییتر و بقیه این روزها یا نمیاد. واقعیت اینه که نوتیفیکیشن فقط به خود اپ مربوط نیست. روی اندروید تقریباً همه 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.