کدهالیک | codehalic

قابلیت جدید Automate توی Cursor یه قدم جلوتر از اتوماسیون‌های معمولیه. قبلاً هوش مصنوعی فقط کمک می‌کرد کارهای تکراری و از قبل تعریف‌شده خودکار انجام بشن، اما حالا خودِ ساختن و مدیریت اتوماسیون‌ها هم داره به AI سپرده می‌شه. کافیه یه رویداد مثل باز شدن Pull Request، اومدن پیام توی Slack یا حتی یه Webhook رو به عنوان تریگر مشخص کنی؛ بعد Cursor خودش Agent مناسب رو اجرا می‌کنه، کار رو انجام می‌ده و نتیجه رو تحویل می‌ده. انگار کم‌کم داریم وارد دوره‌ای می‌شیم که دیگه فقط کارها اتوماتیک نمی‌شن، بلکه خودِ اتوماسیون‌ها هم به صورت خودکار ساخته و مدیریت می‌شن. به نوعی داریم به مرحله‌ای می‌رسیم که هوش مصنوعی نه فقط کارها، بلکه فرآیند طراحی و اجرای اتوماسیون‌ها رو هم بر عهده می‌گیره. @codehalics | کدهالیک

دینو توی نسخه جدیدش (v2.9.0) یه قابلیت فوق‌العاده خفن به اسم deno desktop معرفی کرده که رسماً قراره ساخت اپلیکیشن دسکتاپ با تکنولوژی‌های وب رو دگرگون کنه و رقیب جدی ابزارهایی مثل الکترون و تائوری بشه. با این ویژگی می‌تونید هر پروژه‌ای رو، از یه فایل ساده تایپ‌اسکریپت گرفته تا فریم‌ورک‌های مدرن مثل Next.js، Vite، Astro، Nuxt و SvelteKit، بدون نیاز به هیچ تغییر کدی مستقیم به یک فایل اجرایی مستقل و بومی برای ویندوز، مک و لینوکس تبدیل کنید. جذابیت اصلیش اینجاست که برخلاف تائوری و الکترون، ارتباط بین فرانت‌اَند و بک‌اَندش به صورت درون‌پردازشی (In-process bindings) هست و نیازی به رفت‌وبرگشت‌های سنگین شبکه یا IPC نداره که سرعتش رو فضایی می‌کنه. حجم خروجی خیلی پایینی داره چون پیش‌فرض از وب‌ویو خود سیستم‌عامل استفاده می‌کنه (البته می‌تونید برای یکپارچگی رندرینگ، کرومیوم رو هم توش باندل کنید)، کاملاً با پکیج‌های npm سازگاره، قابلیت آپدیت خودکار هوشمند داخلی داره و از همه بهتر اینکه می‌تونید روی یک سیستم، برای هر سه پلتفرم خروجی بگیرید (Cross-compile). خلاصه که ساخت اپ دسکتاپ با وب از همیشه سریع‌تر، سبک‌تر و لذت‌بخش‌تر شده! https://docs.deno.com/runtime/desktop/ @codehalics | کدهالیک

یکی از بزرگترین دغدغه‌های ما موقع کار با ابزارهایی مثل نوشن اینه که دیتامون روی کلاد ذخیره می‌شه و با یه اختلال یا قطعی اینترنت کل کارمون مختل می‌شه. ابزار Anytype دقیقاً برای حل همین مشکل طراحی شده چون از معماری لوکال فرست استفاده می‌کنه و تمام اطلاعات رو روی دستگاه خودتون ذخیره می‌کنه تا بدون نیاز به اینترنت و با سرعت بالا کار کنه. جذابیت اصلی این ابزار در قابلیت سینک نظیر به نظیر هست که اجازه میده گوشی و لپ‌تاپ شما فقط با وصل بودن به یک شبکه لوکال مشترک و بدون نیاز به اینترنت جهانی دیتای جدید رو با هم همگام‌سازی کنن. علاوه بر این، به خاطر رمزنگاری کامل اطلاعات امنیت فوق‌العاده‌ای داره و ساختار گراف‌محور اون بهتون کمک می‌کنه تا اطلاعات رو به جای فولدرهای تو در تو، بر اساس ارتباطات منطقی سازماندهی کنید و یک سیستم مدیریت دانش کاملاً مستقل و پایدار داشته باشید. https://anytype.io/ @codehalics | کدهالیک

سوال سیستم دیزاین :

بچه‌ها این بحث لور، داکر و درخت مرکل پتانسیل این رو داره که تبدیل به یه سؤال دیزاین سیستمی (System Design) فوق‌العاده جذاب و چالش‌برانگیز برای مصاحبه‌های فنی بشه. فرض کنید توی یه مصاحبه کاری نشستید و این مسئله رو براتون مطرح می‌کنن: ما یه پلتفرم داریم که میلیون‌ها کاربر هروز فایل‌های حجیم مالتی‌مدیا و سه‌بعدی (مثلاً بالای ۱۰ گیگابایت) روش آپلود می‌کنن. این کاربران مدام فایل‌هاشون رو ادیت و آپدیت می‌کنن. چطوری سیستمی رو دیزاین می‌کنید که بتونه با کمترین مصرف پهنای باند و کمترین فضای ذخیره‌سازی، زیر چند ثانیه بخش‌های تغییرکرده‌ی فایل رو تشخیص بده و فقط همون تیکه‌ها رو به سرور منتقل کنه؟ ایده‌هاتون رو توی کامنت‌ها بنویسید تا فردا پاسخ و تحلیل کامل معماریش رو براتون بذارم. @codehalics | کدهالیک

توی کامنت‌ها یکی از بچه‌ها پرسیده بود پس تکلیف Git LFS چی میشه؟ مگه اون برای مدیریت فایل‌های سنگین نیست؟ حرفش کاملاً درسته، ال‌اف‌اس تا الان کارمون رو راه می‌انداخت ولی حقیقتش اینه که LFS بیشتر شبیه یه وصله‌پینه روی ساختار قدیمی و کدمحور گیته. بزرگ‌ترین مشکلش اینه که اگه یه فایل چند گیگابایتی داشته باشید و فقط یه تغییر کوچیک توش بدید، ال‌اف‌اس متوجه تفاوت‌ها نمیشه و مجبور میشه کل اون فایل غول‌آسا رو دوباره از اول آپلود و ذخیره کنه. واسه همین توی پروژه‌های بزرگ مالتی‌مدیا و بازی‌سازی، بعد از یه مدت سیستم شدیداً کند و کلافه‌کننده میشه. اما لور اومده که دقیقاً همین نقطه ضعف رو برطرف کنه. این سیستم فایل‌ها رو به تیکه‌های کوچیک‌تر خرد می‌کنه و موقع ادیت، فقط همون تیکه‌ای که تغییر کرده رو جابه‌جا می‌کنه که این یعنی سرعت فضایی و صرفه‌جویی شدید توی هارد و پهنای باند. از اون طرف، موقع سوییچ کردن بین برنچ‌ها کل پروژه رو براتون دانلود نمی‌کنه و فایل‌های سنگین رو فقط دقیقاً همون لحظه‌ای که موتور بازی یا نرم‌افزارتون بهش نیاز داره فراخوانی می‌کنه. خلاصه که ال‌اف‌اس یه ابزار جانبی برای گیته، ولی لور یه معماری کاملاً جدید و بومی برای دیتای غول‌آساست. @codehalics | کدهالیک

اگه با پروژه‌های بزرگ سر و کار داشته باشید، حتماً می‌دونید که گیت (Git) با همه خفنی‌اش، وقتی پای فایل‌های باینری سنگین مثل ویدیوها، مدل‌های سه‌بعدی و است‌های گرافیکی وسط میاد چقدر اذیت می‌کنه. حالا شرکت معروف اپیک گیمز (Epic Games) اومده یه سیستم کنترل نسخه متن‌باز و کاملاً جدید به اسم Lore معرفی کرده که دقیقاً برای حل همین مشکل ساخته شده. این سیستم طوری طراحی شده که می‌تونه حجم عظیمی از کد و فایل‌های باینری غول‌آسا رو بدون افت سرعت مدیریت کنه، یعنی همون چیزی که بازی‌سازها و توسعه‌دهنده‌های مالتی‌مدیا سال‌هاست منتظرش هستن. معماری Lore فوق‌العاده هوشمندانه است. این سیستم از درخت مرکل (Merkle tree) و ذخیره‌سازی محتوا‌محور استفاده می‌کنه و فایل‌های بزرگ رو تیکه‌تیکه می‌کنه تا فشرده‌سازی و انتقال دیتای تکراری به حداقل برسه. جذاب‌ترین ویژگی‌اش اینه که ورک‌اسپیس‌ها رو سبک نگه می‌داره و فایل‌ها رو فقط زمانی که واقعاً بهشون نیاز دارید دانلود می‌کنه. خبر خوب اینه که کاملاً رایگان و با لایسنس MIT منتشر شده و برای زبان‌های محبوب مثل سی‌شارپ، راست، گو و پایتون هم SDK رسمی داده تا بتونید راحت با سیستم‌های خودتون یکپارچه‌اش کنید. پیشنهاد می‌کنم حتماً یه نگاهی بهش بندازید چون احتمالاً آینده مدیریت پروژه‌های بزرگ دست همین ابزار باشه. https://lore.org @codehalics | کدهالیک

بچه‌ها بالاخره بعد از ۱۰ سال انتظار و کلی بحث و جدل، متد جدید HTTP به اسم QUERY رسماً تایید شد و با شماره RFC 10008 اومد بیرون! داستان از این قراره که تا الان وقتی می‌خواستیم کلی فیلتر پیچیده بنویسیم و یه دیتای خاص رو از سرور بگیریم، یا باید یه لینک کیلومتری با کوئری‌استرینگ‌های طولانی می‌ساختیم که هم محدودیت حجم داشت و هم توی لاگ‌های سرور لو می‌رفت، یا اینکه مجبور بودیم از متد POST استفاده کنیم. اما POST ذاتاً برای ایجاد تغییرات طراحی شده و ویژگی Idempotent (تکرارپذیری امن) رو نداره. متد QUERY دقیقاً برای حل همین مشکل متولد شده تا این جای خالی رو پر کنه. این متد جدید ویژگی‌های خوبِ هر دوتا رو ترکیب کرده؛ یعنی مثل GET کاملاً امن و تکرارپذیره و دیتای سرور رو تغییر نمیده، ولی مثل POST بهتون اجازه میده دیتای پیچیده و فیلترهاتون رو داخل بادی (Body) درخواست بفرستید. خلاصه که دوران چپاندن جی‌سان‌های غول‌آسا توی ساختار URL داره تموم میشه. البته احتمالاً چند سالی زمان می‌بره تا همه مرورگرها، پروکسی‌ها و لودبالانسرها باهاش کاملاً هماهنگ بشن، ولی بدون شک این یکی از جذاب‌ترین و بزرگ‌ترین تغییرات معماری وب توی این چند سال اخیر به حساب میاد. https://www.rfc-editor.org/info/rfc10008/ @codehalics | کدهالیک

ایران درست میشه وضعیت ایران : @codehalics | کدهالیک

ورسل یه فریم‌ورک جدید معرفی کرده به اسم Eve؛ خلاصه‌اش اینه که می‌خواد برای ساخت AI Agent همون کاری رو بکنه که Next.js برای ساخت وب‌اپ کرد. یعنی به‌جای اینکه هر تیم از صفر بیاد برای ایجنتش کلی چیز تکراری بسازه، مثل اتصال به ابزارها، اجرای امن کد، مدیریت پرامپت، لاگ و تریس، Approval انسانی، تست و دیپلوی، Eve این زیرساخت‌ها رو آماده می‌ده. توی Eve یه ایجنت عملاً یه پوشه‌ست؛ یه فایل برای مدل، یه فایل برای دستورالعمل‌ها، یه فولدر برای ابزارها، یکی برای skillها، یکی برای subagentها، یکی برای کانال‌هایی مثل Slack و Telegram و GitHub. نیازش هم دقیقاً از اینجا میاد که ساختن Agent واقعی فقط این نیست که یه LLM صدا بزنی و بگی فلان کار رو بکن. وقتی Agent قراره توی محصول واقعی کار کنه، باید وسط کار کرش نکنه، بتونه چند ساعت یا چند روز یه فرآیند رو ادامه بده، برای کارهای حساس از آدم تأیید بگیره، کدی که تولید می‌کنه رو توی محیط امن اجرا کنه، به سرویس‌هایی مثل GitHub، Slack، Snowflake، Notion و Linear وصل بشه و بشه فهمید دقیقاً چه کاری کرده و کجا اشتباه کرده. Eve می‌خواد این تکه‌های پراکنده رو تبدیل کنه به یه فریم‌ورک استاندارد برای ساخت Agentهای Production-ready. خلاصه اگر قبلاً هر تیم داشت Agent خودش رو با چسب و سیم می‌ساخت، Vercel می‌گه بیاید از این به بعد براش اسکلت و معماری درست داشته باشیم. https://vercel.com/blog/introducing-eve @codehalics | کدهالیک

اگه Mac بی‌کار با چیپ Apple Silicon دارید، می‌تونید به استخر darkbloom اضافه کنید تا به صورت encrypt شده مدل‌های اُپن سورس روش ران بشه و ازش درآمد ماهیانه داشته باشید. مثلا Macbook با چیپ M1 Pro و 32 گیگ رم، اگه مدل Gemma 4 رو ۲۴ روز در ماه ران کنه، حدود ۹۰ دلار پاداش می‌گیرید! بچه‌هایی که کریپتویی هستن شاید شرکت پشت سرش به اسم EigenLayer واسشون آشنا باشه! جدیدا هم با OpenRouter برای ساپلای کردن inference قرارداد بستن! darkbloom.dev Amir @codehalics | کدهالیک

کلا عمو ماسک بر خلاف عمو بابک سمت هر چیزی رفته چندین پله بهترش کرده بنظرم اولین قدمش برای رقابت با دنیای Claude Code و AntiGravity و این چیزا اینه که بره یه چیز قدرتمند و خفنی مثل کرسر رو بخره و قطعا مدلای Grok طی چندین ماه آینده حرف های زیادی روی برنامه نویسی هم دارن و تجربه نشون داده که عمو ماسک همیشه تسهیل گری کرده که یه چیزی بیشتر دیده بشه با اینکه عقاید گاهان چپ گرایانه ای هم از خودش بروز میده ولی من امیدوارم که یه تکونی به قیمت گذاری های آنتروپیک و اینا میده چون الان واقعا GROK هیچ حرفی توی برنامه نویسی و کد زدن واقعا نداره بیشتر بخاطر داشتن دیتای توییتر میتونه راجب اتفاقات روز و تحلیل روزمره و اینا کمک کنه @codehalics | کدهالیک

یه خبر عجیب و مهم از دنیای ابزارهای برنامه‌نویسی: طبق گزارش BBC، اسپیس‌ایکس داره Cursor رو می‌خره؛ همون ادیتور هوشمندی که خیلی از دولوپرها این یکی دو سال باهاش کد زدن و عملاً تبدیل شده به یکی از جدی‌ترین ابزارهای AI coding. نکته مهم خبر فقط خود خرید نیست، اینه که ابزارهای کدنویسی با هوش مصنوعی دیگه یه فیچر خوشگل کنار IDE نیستن؛ دارن تبدیل می‌شن به دارایی استراتژیک شرکت‌های بزرگ. یعنی هر شرکتی که مدل، compute، دیتای توسعه نرم‌افزار و workflow دولوپرها رو با هم داشته باشه، می‌تونه توی موج بعدی تولید نرم‌افزار دست بالاتر رو بگیره. حالا باید دید Cursor بعد از این خرید مستقل و چندمدلی می‌مونه یا کم‌کم به سمت اکوسیستم Grok و xAI کشیده می‌شه. لینک خبر: https://www.bbc.com/news/articles/cvgd5g7d7gyo @codehalics | کدهالیک

کلا هر چیزی از هر کسی میخواین باز کنین روی سیستمتون یه VM زحمت بکشید بیارید بالا الانم که ماشاله انواع و اقسامش هست از Virtual Box گرفته تا روی مک از UTM میتونین استفاده کنین مثلا که خیلی ابزار خوبیه یه ایمیج ویندوز یا ایمیج اوبنتو روش نصب میکنین وسط مک بوک مثلا یه ویندوزم داری که کاملا ایزوله اس هیچ دیتاییم ک روش نداری همه اینارو برو اونجا باز کن چک کن چون یه سری از اینا دیتاهارو میدزدن یه سری سیستمت قفل میکنن و کلی داستان این شکلی پس برادرانه یه VM همیشه داشته باش هر اتفاقی رو روی اون تست کن هر اتفاقیم بیوفته تهش اینه فایلای سیستمی اونو پاک میکنه و اتفاقی برای سیستم نمیوفته @codehalics | کدهالیک

جالبه که این دقیقاً همون چیزیه که npm توی نسخه ۱۲ داره جدی‌تر جلوش رو می‌گیره؛ یعنی دیگه قرار نیست هر dependency همین‌طوری موقع نصب، اسکریپت‌های preinstall و install و postinstall خودش رو اجرا کنه، مگر اینکه خود پروژه صراحتاً بهش اجازه داده باشه. این مورد رو ما قبلا توی کانال بررسی کردیم که تغییرات npm 12 چیه و حتما اپدیت کنین که گیر همچین آدمای مزدوری نیوفتین ! @codehalics | کدهالیک

راز رکورتر های قلابی توی لینکدین که این روزا حسابی زیاد شدن یه داستان واقعی که برای یکی از دوستای منم پیش اومده، همین مدلیه: یه سری آدم میان پیام می‌دن که شما برای فلان پوزیشن خیلی فیت هستی، رزومه‌ات رو دیدیم، پروژه‌هات جذابه، بیا یه تسک کوچیک انجام بده یا این ریپو رو ببین. ظاهر ماجرا خیلی حرفه‌ای و عادیه؛ انگار داری وارد یه فرآیند جذب معمولی می‌شی. ولی مشکل از جایی شروع می‌شه که همون «تسک کوچیک» می‌تونه یه تله باشه. توی این مقاله هم دقیقاً همین اتفاق افتاده؛ به طرف یه ریپوی گیت‌هاب دادن که مثلاً بررسیش کنه، اما داخل پروژه یه بک‌دور قایم کرده بودن که با نصب dependencyها فعال می‌شده. یعنی دیگه فقط لینک ناشناس و فایل exe خطرناک نیست؛ حتی یه پروژه گیت‌هاب برای مصاحبه کاری هم می‌تونه آلوده باشه. مخصوصاً برای بچه‌های فنی، قبل از اجرای هر پروژه ناشناس، بهتره توی محیط ایزوله، VM یا کانتینر بررسیش کنن و هیچ‌وقت همین‌طوری روی سیستم اصلی npm install نزنن. اصل مقاله رو اینجا بخونید: https://roman.pt/posts/linkedin-backdoor/ @codehalics | کدهالیک

۱. بررسی تاریخچه لاگین‌ها و خاموشی‌ها (last -x) اولین قدم این بود که ببینیم آیا کسی دکمه خاموشی رو زده؟ خروجی دستور last نشون داد که آخرین باری که سرور به صورت نرمال shutdown شده، مربوط به ماه‌ها پیش بوده. ۲. مدرک سخت‌افزاری: وحشتِ سیستم‌فایل (recovering journal) وقتی لینوکس نرمال خاموش میشه، درایوها رو با احترام می‌بنده (Unmount). ما رفتیم سراغ لاگ‌های لحظه روشن شدن سرور با دستور: journalctl -b | grep -i "recovering journal" چی پیدا کردیم؟ دیدیم سرویس systemd-fsck به شدت درگیر ریکاوری کردن پارتیشن‌های sda2، lv_var و lv_home شده! این یعنی درایوها در حالت کثیف (Dirty) رها شده بودن و برقشون یهو قطع شده بوده. این اولین "تیر خلاص" به ادعای پشتیبانی بود. ۳. مدرک اپلیکیشنی: اعترافِ پستگرس (PostgreSQL) دیتابیس‌ها به شدت روی داده‌ها حساسن. ما رفتیم سراغ لاگ کانتینر دیتابیس: docker logs <container_id> چی پیدا کردیم؟ این شاه‌بیتِ ماجرا بود! پستگرس لاگ انداخته بود که: database system was not properly shut down; automatic recovery in progress یعنی دیتابیس وسط کار خفه شده بود! تازه پستگرس زمان دقیق قطعی رو هم لو داد: ۱۴ ژوئن ساعت ۲۱:۳۱. اینجا دیگه ۱۰۰٪ مطمئن شدیم که سرور به صورت Hard Power Cut خاموش شده. ۴. مدرک پلتفرمی: تقلای انجین داکر (Docker Daemon) برای اینکه نشون بدیم حتی داکر هم غافلگیر شده، لاگ‌های سرویس داکر رو چک کردیم: journalctl -u docker.service -b چی پیدا کردیم؟ ده‌ها خط ارور با عنوان Removing stale sandbox. این نشون داد که داکر نتونسته در زمان قطعی، سیگنال SIGTERM رو به کانتینرها بفرسته و محیط‌های شبکه‌ای (Sandboxes) رو به درستی پاک کنه. در نتیجه موقع روشن شدن، مجبور شده زباله‌های به‌جا مونده از دفعه قبل رو دستی پاک کنه. ۵. اثبات بی‌گناهی لینوکس (رد کردن ادعای کِرَش) برای اینکه پشتیبانی نتونه بگه "لینوکس خودتون باگ خورده و هنگ کرده": پوشه کرش‌های هسته لینوکس (/var/crash/) رو چک کردیم و دیدیم total 0 (کاملاً خالی) است. یعنی کرنل لینوکس در کمال سلامت بوده. تاریخچه دستورات ترمینال رو هم چک کردیم (history) و هیچ دستور خاموشی‌ای در زمان قطعی پیدا نشد. با کنار هم گذاشتن این پازل‌ها (لایه سخت‌افزار + لایه سیستم‌عامل + لایه پلتفرم + لایه اپلیکیشن)، ما یک پرونده قطعی ساختیم. نتیجه این T-Shoot: به جای اینکه با پشتیبانی سرِ اینکه "کی مقصره" دعوا کنیم، مدارک فنی رو کوبیدیم روی میز! بهشون ثابت کردیم که سیستم‌عامل، داکر و دیتابیس ما همگی گزارش یک قطعی ناگهانی برق یا Force Stop از سمت هایپروایزرِ اون‌ها رو دادن. @codehalics | کدهالیک

سناریویی که اتفاق افتاد این بود داستان از این قرار بود که سرور لینوکس شما که میزبان سرویس‌های حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری می‌کنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!" در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز T-Shoot (ترابل‌شوتینگ) بشیم و از خود سیستم‌عامل به عنوان شاهد استفاده کنیم. @codehalics | کدهالیک

داستان از این قرار بود که سرور لینوکس (اوبونتو ۲۴.۰۴) شما که میزبان سرویس‌های حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری می‌کنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"

قبل از اینکه بریم سراغ مچ‌گیری از دیتاسنتر، بیاید اول با یک اصطلاح خفن مهندسی آشنا بشیم: ترابل‌شوتینگ (Troubleshooting) که تو تیم‌های فنی بهش میگن «تی‌شوت» (T-Shoot) کردن. تی‌شوت کردن یعنی چی؟ تی‌شوت کردن یعنی پیدا کردنِ ریشه‌ی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشم‌بسته عمل کردن. خیلی وقت‌ها وقتی سرور یا اپلیکیشن می‌خوابه، برنامه‌نویس‌های تازه‌کار شروع می‌کنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ری‌استارت می‌کنن. به این کار میگن Trial and Error (آزمون و خطا). اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تی‌شوت می‌کنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه: «من حدس نمی‌زنم، من لاگ‌ها رو می‌خونم.» در واقع، تی‌شوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگ‌های سیستم‌عامل، دیتابیس و کانتینرها، پازل‌ها رو کنار هم می‌چینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده. @codehalics | کدهالیک

خب درست شد سایت و حالا بیاید موشکافی کنیم که در همچین لحظاتی باید چیکار کرد! @codehalics | کدهالیک