نسخه جدید Docker Desktop 4.77 منتشر شد؛ آپدیتی که بیشتر روی پایداری، دیباگ و بهبود تجربه توسعهدهندهها تمرکز دارد. در این نسخه امکان خروجی گرفتن از لاگها اضافه شده، جستوجوی لاگها قابلیت Case-sensitive گرفته، ابزارهای اصلی مثل Docker Engine، Buildx، containerd، Docker Agent و MCP Gateway آپدیت شدهاند و نصب و آپدیت اکستنشنها هم با pinned manifest digest امنتر شده است. در کنار اینها، چند باگ مهم هم در Windows و WSL رفع شده؛ از جمله مشکل گیر کردن Docker Engine در حالت Starting و مشکل خروج تمیز از برنامه در Windows Containers mode.
https://docs.docker.com/desktop/release-notes/
@codehalics | کدهالیک
https://docs.docker.com/desktop/release-notes/
@codehalics | کدهالیک
Docker Documentation
Docker Desktop release notes
Find the Docker Desktop release notes for Mac, Linux, and Windows.
یه ایده ساده ولی خیلی مهم توی طراحی محصول هست به اسم «Every Frame Perfect»؛ یعنی اگر از اپلیکیشنت در هر لحظهای اسکرینشات بگیری، همون فریم هم باید قابلفهم، تمیز و منطقی باشه. نه فقط حالت نهایی صفحه، نه فقط وقتی لودینگ تموم شده، نه فقط وقتی انیمیشن کامل شده؛ حتی وسط جابهجایی بین دو صفحه، وسط لود شدن دیتا، وسط انیمیشنها و تغییر وضعیتها هم UI نباید شلخته و نصفهنیمه به نظر بیاد.
حرف مقاله اینه که کاربر کد ما رو نمیبینه، معماری ما رو نمیفهمه و نمیدونه پشت محصول چقدر زحمت کشیده شده؛ تنها چیزی که میبینه همون رابط کاربریه. وقتی صفحه سفید فلش میزنه، محتوا نصفه لود میشه، دکمهها میپرن، انیمیشنها با هم سینک نیستن یا یک جای اپ میگه «در حال بررسی» و جای دیگه میگه «یک آپدیت موجوده»، ناخودآگاه حس میکنه محصول خامه. شاید مشکل کوچیک باشه، ولی اعتماد کاربر دقیقاً از همین جزئیات ریز ساخته یا خراب میشه. خلاصه اینکه UI خوب فقط طراحی قشنگ در حالت نهایی نیست؛ مسیر رسیدن به اون حالت هم باید تمیز، دقیق و قابلاعتماد باشه.
https://tonsky.me/blog/every-frame-perfect/
@codehalics | کدهالیک
حرف مقاله اینه که کاربر کد ما رو نمیبینه، معماری ما رو نمیفهمه و نمیدونه پشت محصول چقدر زحمت کشیده شده؛ تنها چیزی که میبینه همون رابط کاربریه. وقتی صفحه سفید فلش میزنه، محتوا نصفه لود میشه، دکمهها میپرن، انیمیشنها با هم سینک نیستن یا یک جای اپ میگه «در حال بررسی» و جای دیگه میگه «یک آپدیت موجوده»، ناخودآگاه حس میکنه محصول خامه. شاید مشکل کوچیک باشه، ولی اعتماد کاربر دقیقاً از همین جزئیات ریز ساخته یا خراب میشه. خلاصه اینکه UI خوب فقط طراحی قشنگ در حالت نهایی نیست؛ مسیر رسیدن به اون حالت هم باید تمیز، دقیق و قابلاعتماد باشه.
https://tonsky.me/blog/every-frame-perfect/
@codehalics | کدهالیک
❤1
این مقاله یه نکته مهم درباره کار با AI و مخصوصاً AI Coding میگه: خیلی به «کانتکست بزرگ» مدلها اعتماد نکنین. اینکه یه مدل میگه ۲۰۰ هزار، یک میلیون یا حتی دو میلیون توکن کانتکست داره، الزاماً یعنی همه اون اطلاعات رو با کیفیت خوب نمیفهمه و نگه نمیداره. نویسنده میگه کانتکست مدلها یه فضای کاملاً هوشمند و یکدست نیست؛ انگار یه بخشی ازش «منطقه باهوش»ه که مدل هنوز دقیق و تیز کار میکنه، ولی وقتی چت خیلی طولانی میشه و فایلها، لاگها، تستها و توضیحات زیاد واردش میکنی، کمکم وارد «منطقه کندتر و گیجتر» میشه.
این دقیقاً برای برنامهنویسها مهمه؛ چون وقتی با Coding Agent کار میکنی، خیلی راحت وسوسه میشی کل ریپو، چندتا فایل، لاگ خطا، خروجی تست و کلی توضیح رو بریزی توی یه سشن و انتظار داشته باشی مدل همهچیز رو مثل اول بفهمه. اما واقعیت اینه که مدل ممکنه وسط کار جزئیات مهم رو فراموش کنه، تصمیمهای قبلی یادش نمونه یا روی بخشهای کماهمیت زیادی گیر بده. پیشنهاد مقاله اینه که با کانتکست مثل بودجه رفتار کنیم: سشنها رو بیش از حد طولانی نکنیم، خروجیهای مهم رو خودمون تبدیل کنیم به یه سند کوچیک، اسپک، پلن یا خلاصه دقیق و برای ادامه کار، یه سشن تازه رو با همون اطلاعات تمیز و ضروری شروع کنیم. خلاصه اینکه بهجای اینکه همهچیز رو داخل یه چت بیپایان نگه داریم، بهتره کار رو مرحلهبهمرحله و با مستندات کوچیک و قابلاتکا جلو ببریم.
https://garrit.xyz/posts/2026-05-06-dont-trust-large-context-windows
@codehalics | کدهالیک
این دقیقاً برای برنامهنویسها مهمه؛ چون وقتی با Coding Agent کار میکنی، خیلی راحت وسوسه میشی کل ریپو، چندتا فایل، لاگ خطا، خروجی تست و کلی توضیح رو بریزی توی یه سشن و انتظار داشته باشی مدل همهچیز رو مثل اول بفهمه. اما واقعیت اینه که مدل ممکنه وسط کار جزئیات مهم رو فراموش کنه، تصمیمهای قبلی یادش نمونه یا روی بخشهای کماهمیت زیادی گیر بده. پیشنهاد مقاله اینه که با کانتکست مثل بودجه رفتار کنیم: سشنها رو بیش از حد طولانی نکنیم، خروجیهای مهم رو خودمون تبدیل کنیم به یه سند کوچیک، اسپک، پلن یا خلاصه دقیق و برای ادامه کار، یه سشن تازه رو با همون اطلاعات تمیز و ضروری شروع کنیم. خلاصه اینکه بهجای اینکه همهچیز رو داخل یه چت بیپایان نگه داریم، بهتره کار رو مرحلهبهمرحله و با مستندات کوچیک و قابلاتکا جلو ببریم.
https://garrit.xyz/posts/2026-05-06-dont-trust-large-context-windows
@codehalics | کدهالیک
garrit.xyz
Don't trust large context windows | Garrit's Notes
Generalist software developer writing about scalable infrastructure, fullstack development and DevOps practices.
کدهالیک | 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...
👍3
تلگرام قابلیت های جدیدی به بخش فرمتینگ اضافه کرده همون بخشی که میتونی متنت بولد کنی یا مارک داون بنویسی
از الان میتونی فرمول ریاضی هم توش بنویسی و یا استراکچر بدی به پیامات یا پیام طولانی مینویسی دکمه مشاهده بیشتر برات فعال کنه تا جایی که میخوای و کلی چیز جالب دیگ
از این بات میتونین قابلیت های جدید فرمتینگ تلگرام رو ببینید !
@richtextdemobot
@codehalics | کدهالیک
از الان میتونی فرمول ریاضی هم توش بنویسی و یا استراکچر بدی به پیامات یا پیام طولانی مینویسی دکمه مشاهده بیشتر برات فعال کنه تا جایی که میخوای و کلی چیز جالب دیگ
از این بات میتونین قابلیت های جدید فرمتینگ تلگرام رو ببینید !
@richtextdemobot
@codehalics | کدهالیک
❤9
خب بچه ها دیدم خیلی پیام و اینا هست سرور کدهالیک از صبح از دسترس خارج شده و منم دسترسی بهش ندارم حالا یا اینترنتش قطع شده یا اتک خورده یا هر چیزی منتظرم که اونجایی ک ازش سرور گرفتم جواب بهم بده که چرا سرور از دسترس خارج شده برای همین احتمالا یه تایمی داون خواهیم بود تا دوباره برگرده و اینا
خلاصه که ایشاله خیره امیدوارم که چیزیش نشده باشه 😁
@codehalics | کدهالیک
خلاصه که ایشاله خیره امیدوارم که چیزیش نشده باشه 😁
@codehalics | کدهالیک
❤3🤯2
قبل از اینکه بریم سراغ مچگیری از دیتاسنتر، بیاید اول با یک اصطلاح خفن مهندسی آشنا بشیم: ترابلشوتینگ (Troubleshooting) که تو تیمهای فنی بهش میگن «تیشوت» (T-Shoot) کردن.
تیشوت کردن یعنی چی؟
تیشوت کردن یعنی پیدا کردنِ ریشهی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشمبسته عمل کردن.
خیلی وقتها وقتی سرور یا اپلیکیشن میخوابه، برنامهنویسهای تازهکار شروع میکنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ریاستارت میکنن. به این کار میگن Trial and Error (آزمون و خطا).
اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تیشوت میکنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:
«من حدس نمیزنم، من لاگها رو میخونم.»
در واقع، تیشوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگهای سیستمعامل، دیتابیس و کانتینرها، پازلها رو کنار هم میچینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده.
@codehalics | کدهالیک
تیشوت کردن یعنی چی؟
تیشوت کردن یعنی پیدا کردنِ ریشهی یک مشکل (Root Cause) به صورت سیستماتیک و علمی، به جای حدس زدن و چشمبسته عمل کردن.
خیلی وقتها وقتی سرور یا اپلیکیشن میخوابه، برنامهنویسهای تازهکار شروع میکنن به حدس زدن: "شاید رم پر شده؟ شاید کد من باگ داره؟ شاید دیتابیس قفل کرده؟" و الکی سرور رو ریاستارت میکنن. به این کار میگن Trial and Error (آزمون و خطا).
اما یک مهندس ارشد (Senior) وقتی با قطعی مواجه میشه، تیشوت میکنه. یعنی مثل یک کارآگاه جنایی وارد صحنه جرم میشه و میگه:
«من حدس نمیزنم، من لاگها رو میخونم.»
در واقع، تیشوت کردن هنره تبدیل شدن به یک وکیل مدافع برای کدهای خودتونه! شما با بررسی لاگهای سیستمعامل، دیتابیس و کانتینرها، پازلها رو کنار هم میچینید تا دقیقاً بفهمید تو ثانیه صفرِ اون اتفاق چه بلایی سر سیستم اومده.
@codehalics | کدهالیک
❤2
سناریویی که اتفاق افتاد این بود
داستان از این قرار بود که سرور لینوکس شما که میزبان سرویسهای حساسی مثل دیتابیس پستگرس روی داکر بود، ناگهان خاموش شده و از دسترس خارج میشه. وقتی سرور دوباره روشن میشه و شما از پشتیبانی دیتاسنتر (یا شخصی که سرور رو ازش خریدی) پیگیری میکنی، در جواب میگن: "ما کاری نکردیم، سرور از سمت ما مشکلی نداشته، احتمالاً خودتون از داخل لینوکس دستور خاموشی دادید یا سرورتون کرش کرده!"
در این لحظه، به جای اینکه حرفشون رو بپذیریم یا شروع کنیم به حدس زدن، تصمیم گرفتیم مثل یک مهندس ارشد وارد فاز 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 | کدهالیک
❤6👍2