کدهالیک | codehalic
این مقاله یه نکته مهم درباره کار با AI و مخصوصاً AI Coding میگه: خیلی به «کانتکست بزرگ» مدلها اعتماد نکنین. اینکه یه مدل میگه ۲۰۰ هزار، یک میلیون یا حتی دو میلیون توکن کانتکست داره، الزاماً یعنی همه اون اطلاعات رو با کیفیت خوب نمیفهمه و نگه نمیداره. نویسنده…
دیروز داشتم یه مقاله خیلی جالب روی arXiv برای دانشگاه کرونل رو میخوندم که استاد شریف زارچی معرفیش کرده بود توی ویدیو اخیرش درباره اینکه وقتی با مدلهای زبانی کار میکنیم، «همه اطلاعات رو اول کار بدیم» بهتره یا «کمکم و مرحلهبهمرحله توضیح بدیم». نتیجهاش برای من خیلی مهم بود، چون دقیقاً به تجربه روزمره ما با ChatGPT و ابزارهای AI Coding ربط داره.
مقاله میگه مدلها وقتی کل مسئله، محدودیتها، دیتا و هدف رو همون اول کامل و مرتب میگیرن، معمولاً خیلی بهتر عمل میکنن. ولی وقتی همون اطلاعات رو تکهتکه و وسط مکالمه بهشون میدیم، احتمال اینکه گیج بشن، زود فرض بسازن یا روی مسیر اشتباه قفل کنن بیشتر میشه. یعنی همیشه اینطور نیست که «آرومآروم توضیح دادن» بهترین روش باشه. برای کارهای جدی مثل کدنویسی، تحلیل محصول، نوشتن تسک یا دیباگ، بهتره اول یه تصویر کامل از مسئله بدیم، بعد بریم سراغ اصلاح و رفتوبرگشت.
https://arxiv.org/abs/2505.06120
@codhalics | کدهالیک
مقاله میگه مدلها وقتی کل مسئله، محدودیتها، دیتا و هدف رو همون اول کامل و مرتب میگیرن، معمولاً خیلی بهتر عمل میکنن. ولی وقتی همون اطلاعات رو تکهتکه و وسط مکالمه بهشون میدیم، احتمال اینکه گیج بشن، زود فرض بسازن یا روی مسیر اشتباه قفل کنن بیشتر میشه. یعنی همیشه اینطور نیست که «آرومآروم توضیح دادن» بهترین روش باشه. برای کارهای جدی مثل کدنویسی، تحلیل محصول، نوشتن تسک یا دیباگ، بهتره اول یه تصویر کامل از مسئله بدیم، بعد بریم سراغ اصلاح و رفتوبرگشت.
https://arxiv.org/abs/2505.06120
@codhalics | کدهالیک
arXiv.org
LLMs Get Lost In Multi-Turn Conversation
Large Language Models (LLMs) are conversational interfaces. As such, LLMs have the potential to assist their users not only when they can fully specify the task at hand, but also to help them...
👍4
تلگرام قابلیت های جدیدی به بخش فرمتینگ اضافه کرده همون بخشی که میتونی متنت بولد کنی یا مارک داون بنویسی
از الان میتونی فرمول ریاضی هم توش بنویسی و یا استراکچر بدی به پیامات یا پیام طولانی مینویسی دکمه مشاهده بیشتر برات فعال کنه تا جایی که میخوای و کلی چیز جالب دیگ
از این بات میتونین قابلیت های جدید فرمتینگ تلگرام رو ببینید !
@richtextdemobot
@codehalics | کدهالیک
از الان میتونی فرمول ریاضی هم توش بنویسی و یا استراکچر بدی به پیامات یا پیام طولانی مینویسی دکمه مشاهده بیشتر برات فعال کنه تا جایی که میخوای و کلی چیز جالب دیگ
از این بات میتونین قابلیت های جدید فرمتینگ تلگرام رو ببینید !
@richtextdemobot
@codehalics | کدهالیک
❤10
خب بچه ها دیدم خیلی پیام و اینا هست سرور کدهالیک از صبح از دسترس خارج شده و منم دسترسی بهش ندارم حالا یا اینترنتش قطع شده یا اتک خورده یا هر چیزی منتظرم که اونجایی ک ازش سرور گرفتم جواب بهم بده که چرا سرور از دسترس خارج شده برای همین احتمالا یه تایمی داون خواهیم بود تا دوباره برگرده و اینا
خلاصه که ایشاله خیره امیدوارم که چیزیش نشده باشه 😁
@codehalics | کدهالیک
خلاصه که ایشاله خیره امیدوارم که چیزیش نشده باشه 😁
@codehalics | کدهالیک
❤4🤯3
قبل از اینکه بریم سراغ مچگیری از دیتاسنتر، بیاید اول با یک اصطلاح خفن مهندسی آشنا بشیم: ترابلشوتینگ (Troubleshooting) که تو تیمهای فنی بهش میگن «تیشوت» (T-Shoot) کردن.
تیشوت کردن یعنی چی؟
تیشوت کردن یعنی پیدا کردنِ ریشهی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشمبسته عمل کردن.
خیلی وقتها وقتی سرور یا اپلیکیشن میخوابه، برنامهنویسهای تازهکار شروع میکنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ریاستارت میکنن. به این کار میگن Trial and Error (آزمون و خطا).
اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تیشوت میکنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:
«من حدس نمیزنم، من لاگها رو میخونم.»
در واقع، تیشوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگهای سیستمعامل، دیتابیس و کانتینرها، پازلها رو کنار هم میچینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده.
@codehalics | کدهالیک
تیشوت کردن یعنی چی؟
تیشوت کردن یعنی پیدا کردنِ ریشهی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشمبسته عمل کردن.
خیلی وقتها وقتی سرور یا اپلیکیشن میخوابه، برنامهنویسهای تازهکار شروع میکنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ریاستارت میکنن. به این کار میگن Trial and Error (آزمون و خطا).
اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تیشوت میکنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:
«من حدس نمیزنم، من لاگها رو میخونم.»
در واقع، تیشوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگهای سیستمعامل، دیتابیس و کانتینرها، پازلها رو کنار هم میچینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده.
@codehalics | کدهالیک
❤5
سناریویی که اتفاق افتاد این بود
داستان از این قرار بود که سرور لینوکس شما که میزبان سرویسهای حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری میکنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"
در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز T-Shoot (ترابلشوتینگ) بشیم و از خود سیستمعامل به عنوان شاهد استفاده کنیم.
@codehalics | کدهالیک
داستان از این قرار بود که سرور لینوکس شما که میزبان سرویسهای حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری میکنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"
در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز T-Shoot (ترابلشوتینگ) بشیم و از خود سیستمعامل به عنوان شاهد استفاده کنیم.
@codehalics | کدهالیک
❤2👍1
کدهالیک | codehalic
سناریویی که اتفاق افتاد این بود داستان از این قرار بود که سرور لینوکس شما که میزبان سرویسهای حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی)…
۱. بررسی تاریخچه لاگینها و خاموشیها (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 | کدهالیک
اولین قدم این بود که ببینیم آیا کسی دکمه خاموشی رو زده؟
خروجی دستور 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 | کدهالیک
❤12👍3