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

چرا 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/

An interactive git tutorial meant to teach you how git works, not just which commands to execute. https://dev.to/unseenwizzard/learn-git-concepts-not-commands-4gjc

روایتی از ۵ روز نفس‌گیر؛ زومیت چگونه هک شد و چه درس‌هایی گرفتیم؟ 🔺هک شدن زومیت یک بحران پنج روزه را رقم زد؛ حمله‌ای سایبری که از لایه مجازی‌سازی شبکه داخلی شروع شد و دسترسی به سرویس‌ها را مختل کرد. پس از تلاشی نفس‌گیر، زیرساخت‌ها کاملاً ایمن شده و سرویس‌ها بازگشته‌اند. 🔺مسعود یوسف‌نژاد، مدیرعامل زومیت، جزئیات فنی این نفوذ، آسیب‌ها و راهکارهای بازیابی را در یک ویدیو تشریح می‌کند. هدف، انتقال تجربه‌ است تا دیگر کسب‌وکارها مسیرهای نفوذ مشابه را بشناسند و از بروز چنین رخدادهایی پیشگیری کنند. این یک مسئولیت اجتماعی برای شفافیت و کمک به جامعه فناوری است. #ویدیو #زومیت 🔗 جزئیات فنی هک زومیت و راهکارهای امنیتی 🆔 @thezoomit

توی طراحی دیتابیس، یک سری قاعده داریم به اسم Armstrong Axiom. این‌ها در واقع یه سری قانون رسمی برای استنتاج Functional Dependency‌ها هستن؛ یعنی کمک می‌کنن بفهمیم از روی یه‌سری وابستگی، چه وابستگی‌های دیگه‌ای منطقی نتیجه می‌شن. کاربردش؟ وقتی می‌خوایم نرمال‌سازی انجام بدیم، کلید کاندید پیدا کنیم یا بررسی کنیم یه decomposition درسته یا نه. این ویدیو رو خیلی رندوم پیدا کردم ولی خیلی خوب و تمیز توضیح داده. اگه به بحث‌های تئوری دیتابیس علاقه دارید، مخصوصاً بخش dependency و نرمال‌فرم‌ها، توصیه می‌کنم حتماً ببینید. https://www.youtube.com/watch?v=TWAiz3BWHsw&t=7s

وقتی با AI کدی تولید میکنیم چطوری باهاش رفتار کنیم؟ به عنوان درفت اولیه در نظر بگیریمش. ریویو کنیم، به نحوی که انگار یک جونیور نوشته و بعد مسئولیت کد رو ما قبول کنیم. مطلب جالبی بود و من دیدش رو دوست داشتم. https://addyo.substack.com/p/treat-ai-generated-code-as-a-draft

مساله ژنرال‌های بیزانسی: چرا رسیدن به اجماع سخته؟ یکی از کارهای جالب دیگه‌ی لزلی لمپورت، طراحی یک مساله ذهنی به اسم ژنرال‌های بیزانسی و مطرح کردن خطای بیزانسی بود. تو این مساله چند تا ژنرال وجود دارد و می‌خوان به توافق برسن که یا همه با هم حمله کنن یا همه با هم حمله نکنن ولی چالش‌هایی دارن مثلا پیام‌هاشون به همدیگه ممکنه نرسه یا چند تا imposter بینشون باشه. لازم به ذکره که این مساله توی بلاکچین هم خیلی کاربرد داره و بهش توجه می‌شه چون عملا رسیدن به اجماع در مورد این که چی در سیاهه‌/ledger بیتکوین (برای مثال) وجود داره خیلی برای کارکرد شبکه مهمه. توضیح فارسی خوب: https://blog.magicbytes.ir/byzantine-generals-problem/ توضیح اولیه با ویدیو: https://www.youtube.com/watch?v=dfsRQyYXOsQ توضیح خوب صورت سوال و جواب: www.youtube.com/watch?v=Bvj72wN0OVk

من حفظ کرده بودم که کانتینر از طریق دو فیچر c group و namespace ایزوله سازی می‌کنه ولی درک کاملی نداشتم که دقیقا معنیش چیه این ویدیو پرکتیکال کانتینر رو با محوریت ایزوله سازی از اسکرچ پیاده سازی می‌کنه https://youtu.be/MHv6cWjvQjM

ساعتی که توی سیستم‌ها داریم معمولا با یه کریستال کوارتزی کنترل می‌شه و خب خطا هم داره. برای حل خطاش معمولا سیستم‌ها به یکسری سرور وصل می‌شن و تایمشون رو آپدیت می‌کنن، مثلا با پروتوکل NTP (یا همون network time protocol) که خیلی پروتوکل جالبیه و پیچیدگی‌های بامزه‌ای رو حل می‌کنه (ویدیوی اول رو ببینید) این تنظیم زمان اگرچه خوبه اما یه گارانتی مهم رو از سیستم حذف میکنه: زمان دیگه فقط صعودی نیست!‌ ممکنه بین دو بار پرسیدن زمان، زمان اول از دوم بیشتر باشه! این موضوع به همراه تاخیر شبکه و این که دقت NTP هم بینهایت نیست باعث می‌شه که ما نتونیم تو یه سیستم distributed با خوندن تایم فعلی سیستم و مقایسه‌ش با تایم فعلی یک سیستم دیگه، بفهمیم کدوم یکی از اتفاقات زودتر افتاده. لزلی لمپورت در مقاله معروفش به این مشکل پرداخته. Time, Clocks, and the Ordering of Events in a Distributed System لزلی لمپورت در اصل فیزیک‌دان بوده و با دید فیزیک وارد distributed systemها می‌شه و چیزهای جالبی مثل الگوریتم Paxos و جنرال‌های بیزانسی (یا تحمل خطای بیزانسی) رو اختراع کرده. لمپورت در زمینه ساعت‌ها یه مدل ارائه می‌ده که در اصل یه شمارنده‌ست که سیستم نرم‌افزاری بر اساس اتفاقاتی که برای خودش می‌افته یا پیام‌هایی که می‌فرسته یا می‌گیره بروزرسانی می‌کنه. این ساعت دیگه سعی نمی‌کنه «زمان واقعی دنیا» رو اندازه بگیره، بلکه فقط ترتیب علّی (causal ordering) اتفاقات رو مدل می‌کنه؛ یعنی اگر رویدادی باعث رویداد دیگه‌ای شده باشه، عدد ساعتش هم این رابطه رو حفظ می‌کنه. به این ترتیب بدون اینکه به ساعت فیزیکی یا هماهنگ‌سازی جهانی وابسته باشیم، می‌تونیم بفهمیم کدوم اتفاق قبل از کدوم یکی رخ داده و از همین مفهوم ساده، کلی الگوریتم و تضمین مهم در سیستم‌های توزیع‌شده ساخته می‌شه. https://www.youtube.com/watch?v=Ihm6AYNFUKA https://sookocheff.com/post/time/lamport-clock/ https://martinfowler.com/articles/patterns-of-distributed-systems/lamport-clock.html https://lamport.azurewebsites.net/pubs/time-clocks.pdf

چرا چنل های گولنگ بد هستند؟ این مطلب با مثال های خوب توضیح می‌ده که هم کار رو برای برنامه نویس سخت میکنن هم دیباگشون سخته و هم حتی کند هستند. https://www.jtolio.com/2016/03/go-channels-are-bad-and-you-should-feel-bad/