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

تاریخچه computing در یک ویدیو ۱۳ دقیقه‌ای

https://youtu.be/-M6lANfzFsM

در اندروید چطور یه کار رو برای آینده زمان‌دار کنیم؟ با کمک work manager!
اینجا هم نحوه کارکرد هم apiهای کار باهاش رو توضیح داده.

https://medium.com/@appdevinsights/work-manager-android-6ea8daad56ee

اگر Arch Linux دارید و شک دارید که آلوده شدین یا نه، این اسکریپت رو اجرا کنید.
(البته که توصیه میشه اسکریپت رندوم دانلود و اجرا نکنید!)

میاد یک سری چیزا رو چک می‌کنه شامل کارهایی که اون نرم‌افزار مخرب انجام می‌ده و اثراتی که میگذاره. چک می‌کنه که پترنش با وضعیت فعلی سیستم می‌خونه یا نه. همچنین لاگ‌های پک‌من رو نگاه می‌کنه که ببینه آیا اون پکیجی که نصب کردید در زمانی که شما نصب کردید آلوده بوده یا نه. دقت کنید که صرفا از چک کردن لیست پکیج های نصب شده با لیست هک شده ها متفاوته و به زمان نصبشون و زمان مخرب بودنشون هم نگاه می‌کنه.

https://github.com/lenucksi/aur-malware-check

./aur_check-v2.sh --full

نوشته‌های ترمینالی pinned «یه سوالی که همیشه از من می‌شه اینه که مطالبی که اینجا می‌گذارم رو از کجا میارم. چند سال پیش یه بار بهش جواب داده بودم و دوست داشتم یه بار دیگه بهش جواب بدم. ۱- خیلی از اوقات یه موضوعی به چشمم خورده و در موردش سرچ کردم. مثلا توی کار یا موقع کرش یه اپی که…»

یه سوالی که همیشه از من می‌شه اینه که مطالبی که اینجا می‌گذارم رو از کجا میارم. چند سال پیش یه بار بهش جواب داده بودم و دوست داشتم یه بار دیگه بهش جواب بدم.

۱- خیلی از اوقات یه موضوعی به چشمم خورده و در موردش سرچ کردم. مثلا توی کار یا موقع کرش یه اپی که ازش استفاده می‌کنم.

۲- یکسری محتوا رو خودم سابسکرایب کردم که چیزایی که به نظرم مفید و جالب باشه رو براتون می‌ذارم. یوتوب و توییتر و mailing list (اکثرا تو substack) و چنل‌های تلگرامی و یک سری وبلاگ رندوم که بهشون سر می‌زنم.

۳- یه چیزایی هم تجربه خودمه یا یه موضوعی می‌بینم که حس می‌کنم خوبه در موردش بنویسم که سعی می‌کنم سرچ کنم و مرتب کنم براتون بنویسم.

حالا بین همه‌ی اینا، احتمالا هرکس می‌تونه با تلاش کم، مورد دوم رو برای خودش تقویت کنه، در این زمینه من یه منبع خیلی خوب پیدا کردم که می‌تونه بهتون کمک کنه. در زمینه‌های مختلف محتواهایی که بتونید دنبال کنید و یا بخونید رو آورده که می‌تونه خیلی بهتون کمک کنه. به نظرم تنها ایرادش اینه که آدم دلش می‌خواد همه رو دنبال کنه و اگر زیاد بشه تمرکز از دست می‌ره. من توصیه می‌کنم ۲-۳ تا چنل یوتوب و ۱-۲ تا mailing list رو بیشتر دنبال نکنید تا یه فرصتی بشه که بهشون بپردازید.
در ادامه هم خوبه که بعد یه مدتی به خود سایت substack و قسمت following یوتوبتون سر بزنید ببینید چیا رو دنبال کردید و اگر چیزی رو دنبال کردید که زیاد براتون جالب نیست یا کیفیتش خوب نیست یا به هر دلیلی دوستش ندارید با یکی دیگه جایگزینش کنید.

https://github.com/jordan-cutler/path-to-senior-engineer-handbook

این حرف ها رو اگر کسایی به جز مدیر شرکت های عرضه کننده ai یا سخت افزار ai بزنن من قبول می‌کنم :)
ولی هرچی می‌شنوم از ان‌ویدیا و گوگل و open ai و anthropicئه.

ساندار پیچای، مدیرعامل گوگل: «اگر همین حالا یاد نگیرید چطور عامل‌های هوش مصنوعی (Agents) را مدیریت و هماهنگ کنید، سال ۲۰۲۷ را صرف جبران فاصله با کسانی خواهید کرد که از امروز شروع کرده‌اند.»

او در یک گفت‌وگو توضیح می‌دهد که چرا بهترین مهندسان نرم‌افزار دیگر تمام وقت خود را صرف کدنویسی نمی‌کنند و به جای آن روی ساخت و مدیریت Agentها تمرکز کرده‌اند.

بیشتر افراد تصور می‌کنند برای ساخت یک Agent باید مدرک مهندسی یا دانش فنی بسیار پیشرفته داشته باشند.

اما واقعیت این است که برای شروع، به چنین چیزی نیاز ندارید؛ فقط یک راهنمای مناسب و چند ساعت زمان کافی است.

🆔 @thezoomit

یکی از مباحثی که تو مهندسی به نظرم خیلی مهمه abstraction و abstractionهای درسته. چطور جزئیات لایه پایین رو پنهان کنیم ولی کارایی رو حفظ کنیم و چطوری مدل سطح بالای دقیق‌تری طراحی کنیم.
یکی از چیزایی که به عنوان web developer احتمالا خیلی باهاش درگیر می‌شین استاندارد HTTPئه که در لایه‌های پایین از TCP (و یا جدیدا از UDP در http3) استفاده می‌کنه.
بخوام دقیق تر بگم، ما در زمان استفاده فقط به یک ریکوئست GET یا POST فکر میکنیم ولی اون زیر یه سوکت TCP باز می‌شه و یه سری اطلاعات ارسال و دریافت می‌شه. حالا یه چیزی مثل مرورگر که ده‌ها درخواست به یک یا چند سرور باید بفرسته چی؟ چطوری و چند تا سوکت TCP باز می‌کنه؟ چه زمانی می‌بنده و آیا می‌شه از یک کانکشن TCP همزمان چند تا درخواست http رو عبور داد؟
توی http1.1 یه ایده‌هایی زده بودن ولی خیلی خوب نبود و عملا نمی‌شد یه سرور دیپلوی کرد که به درستی ازش استفاده کنه. این ویژگی که اسمش پایپلاینه میگه چند تا درخواست رو می‌شه از طریق یک tcp connection واحد فرستاد ولی پاسخ‌ها باید به ترتیب از سمت سرور بیاد.
از طرف دیگه توی http2 امکان multiplexing اضافه شد که شرط ترتیب پاسخ‌ها رو حذف می‌کنه و سرور می‌تونه هر پاسخی رو که آماده شد برای کلاینت بفرسته.

https://stackoverflow.com/questions/34478967/what-is-the-difference-between-http-1-1-pipelining-and-http-2-multiplexing

چه ابزارهای AIی در ۲۰۲۶ مورد استفاده هستند و کدوم‌ها محبوبند؟ اندازه شرکت و تجربه کاری چه تاثیری روی این موضوع داره؟‌

https://newsletter.pragmaticengineer.com/p/ai-tooling-2026

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