کدهالیک | codehalic

یه مفهوم من درآوردی دیگ هم داریم به اسم Rubber Duck Debugging معمولا من توی دخترای برنامه نویس دیدم میرن عروسکش میخرن براش باگارو توضیح میدن اگر پسرشو دیدید لطفا گزارش بدید که بریم پیگیری کنیم چی شده اینکارو داره میکنه داستانش اینه که وقتی گیر یه باگ میفتی، شروع می‌کنی مشکل رو مرحله‌به‌مرحله برای یه اردک پلاستیکی زرد توضیح دادن نکته اینجاست که خودِ فرآیند توضیح دادن باعث میشه ذهنت منظم‌تر کار کنه و خیلی وقتا وسط توضیح دادن، خودت متوجه اشتباهت بشی. یعنی لازم نیست حتماً یه آدم دیگه جواب رو بدونه؛ صرف اینکه داری مسئله رو «قابل فهم» توضیح میدی، مغزت باگ رو پیدا می‌کنه. فرقش با Linus’s Law اینه که اون میگه «چشم‌های بیشتر = احتمال بیشتر برای پیدا شدن باگ»، ولی Rubber Duck Debugging میگه «شفاف توضیح دادن مسئله = احتمال بیشتر برای فهمیدن باگ». هردوشون روی این ایده سوارن که باگ وقتی از حالت مبهم توی ذهنت خارج بشه، پیدا کردنش راحت‌تر میشه. البته بازم بگم همه اینارو اون طرفش هوش مصنوعی بزارید دیگ یعنی هوش مصنوعی بشه نقش اون رابر داک و نقش چشم هایی که باید باگ هارو پیدا کنند چون واقعا داریم از اون نسل که باید ساعت ها میشستی دیباگ میکردی تا مشکل پیدا کنی گذر میکنیم چون الان ایزی ایزی کلاد همه اینکارارو به بهترین شکل برات میکنه ! @codehalics | کدهالیک

یک مفهوم من درآوردی دی

من یه پوریا لاو هم دارم ( لاو لایفم رو نمیگم منظورم قانون من در آوردی خودمه) که میگم اگر یه کد رو به چندتا ایجنت هوش مصنوعی بدی معمولا نتیجه بهتری میگیری بنظرم آپدیت این قانون الان اینشکلیه که فقط از جمنای و فقط از کدکس و فقط از کلاد استفاده نکنی تجمیعشون کنی و از تجمیعشون تصمیم بگیری خیلی خیلی برای من این نکته تاثیر گذاشته و دوما تست نویسی ! به هوش مصنوعی میگم تست بنویس برای این سناریو ها حالا هر وقت کدو تغییر بده تست ها پاس نشه میگم دیدی نشد دیدی پی پی کردی تو کد من!! بعد اینطوری میتونم جلوی خیلی از unexpected behaviors هارو بگیرم یه بار پوریا لاو رو تست کنین شگفت زدتون میکنه ! @codehalics | کدهالیک

FYI : For Your Information باگ معروف Heartbleed یه حفره امنیتی خیلی خطرناک توی کتابخونه‌ی OpenSSL بود که سال ۲۰۱۴ کشف شد. OpenSSL همون چیزیه که خیلی از سایت‌ها برای رمزنگاری و HTTPS ازش استفاده می‌کنن. مشکل از یه قابلیت به اسم “Heartbeat” اومده بود؛ هکر می‌تونست به سرور یه درخواست تقلبی بفرسته و سرور بدون بررسی درست، بخشی از حافظه‌ی خودش رو پس بده. تو اون حافظه ممکن بود اطلاعات خیلی حساس مثل پسورد، کوکی لاگین، پیام‌ها یا حتی کلید خصوصی SSL وجود داشته باشه. چیزی که Heartbleed رو ترسناک‌تر کرد این بود که این باگ حدود دو سال توی یه پروژه‌ی اوپن‌سورس بسیار معروف وجود داشت و کسی متوجهش نشده بود. این دقیقاً شد ضد مثال معروف برای Linus’s Law؛ یعنی صرف اینکه کد جلوی چشم همه باشه کافی نیست، باید آدم‌های متخصص واقعاً کد رو بررسی کنن. بعد از افشای باگ، کلی سایت بزرگ مجبور شدن سریع OpenSSL رو آپدیت کنن، سرتیفیکیت‌هاشون رو عوض کنن و از کاربرها بخوان پسوردهاشون رو تغییر بدن. @codehalics | کدهالیک

برای ادامه قوانین مهندسی نرم افزار Linus's Law لینوس لاو یه ایده معروف تو دنیای برنامه‌نویسیه که میگه: «اگه آدم‌های زیادی کد رو ببینن، پیدا کردن باگ‌ها راحت‌تر میشه.» یعنی وقتی یه پروژه اوپن‌سورس باشه و کلی دولوپر و کاربر بهش دسترسی داشته باشن، احتمال اینکه یکی مشکل رو پیدا کنه یا حتی براش راه‌حل بده خیلی بیشتره. چیزی که برای یه برنامه‌نویس پیچیده و گیج‌کننده‌ست، شاید برای یه نفر دیگه خیلی واضح باشه. به خاطر همین پروژه‌هایی مثل لینوکس یا Apache معمولاً سریع‌تر باگ‌هاشون کشف و درست میشه. البته این قانون همیشه هم معجزه نمی‌کنه. فقط اوپن‌سورس بودن کافی نیست؛ باید آدم‌هایی واقعاً در حال بررسی و مشارکت باشن. مثلاً باگ معروف Heartbleed توی OpenSSL دو سال مخفی مونده بود، با اینکه پروژه کاملاً متن‌باز بود. یعنی «چشم زیاد» وقتی مفیده که واقعاً کسی داره نگاه می‌کنه. به همین خاطر این قانون بیشتر از اینکه یه حقیقت مطلق باشه، یه یادآوریه که همکاری، شفافیت و کد ریویو جمعی معمولاً کیفیت نرم‌افزار رو بهتر می‌کنه. #lawsofsoftwareengineering @codehalics | کدهالیک

داخل کار باشه (گروهمون ) به طور اکتیو داریم همه جاب آفر هایی که توی لینکدین و تلگرام و توییتر و باقی سوشال مدیا هست رو باهم شیر میکنیم تا زودتر بتونیم افرادی که تعدیل شدن رو به بازار کار معرفی کنیم اگر مایل بودید حتما جوین بشید به گروهمون @job_bashe

تکراریه ولی این به این منزله اس که هنوز دنبال فرانت دولوپر میگرده Abanro is looking for a Senior Back-End Developer to join our growing product team. We are building a modern platform for social media sales and looking for someone who is comfortable working in a startup environment, takes ownership, and enjoys building scalable systems. Requirements: Strong experience with FastAPI Experience with microservices architecture Hands-on experience with Kafka Solid knowledge of PostgreSQL Familiarity with Redis Experience working with Docker https://forms.gle/j1aKyFbTYWnUDd828 @job_bashe

یکم از مزایای ایرانی بودن بگم براتون که امروز مجبور شدم برای بیلد پروژم ۳۵۰ ت بدم رانفلر اجازه بده از میرورهاش استفاده کنم و قسمت جالب ماجرا اینه که کلا برای سه تا پروژه که بیلد گرفتم و صرفا سیگنیچر پکیج رو چک کرده چون از قبل نود ماژولش رو داشتم ۱۰۰۰ تا از کوت هام مصرف شده و ۲۰۰۰ تا دیگ مونده یعنی خوش بینانه سه بار دیگ میتونم بیلد بگیرم :)))))))) خلاصه این چیزا توی خارج قفله ولی ما داریم تو ایران خیلی جذاب و خنده دار باهاش برخورد میکنیم @codehalics | کدهالیک

سایمون ویلیسون، یکی از معروف‌ترین آدم‌های حوزه AI و برنامه‌نویسی، میگه مرز بین «vibe coding» و برنامه‌نویسی حرفه‌ای با کمک هوش مصنوعی داره کم‌کم از بین میره. قبلاً vibe coding یعنی فقط به AI بگی یه چیزی بسازه بدون اینکه حتی کدهاشو نگاه کنی؛ بیشتر برای پروژه‌های شخصی و فان. ولی الان ابزارهایی مثل Claude Code اون‌قدر خوب شدن که حتی برنامه‌نویس‌های حرفه‌ای هم دارن بدون چک کردن تک‌تک خط‌ها از خروجی AI توی پروژه‌های واقعی استفاده می‌کنن. نکته ترسناک ماجرا اینجاست که خودش اعتراف می‌کنه کم‌کم داره به AI مثل یه هم‌تیمی قابل اعتماد نگاه می‌کنه، نه یه ابزار ساده. یعنی همون‌طور که توی شرکت‌ها همیشه کد تیم‌های دیگه رو کامل نمی‌خونی و فقط بهشون اعتماد می‌کنی، حالا بعضیا دارن همین حس اعتماد رو به agentهای AI پیدا می‌کنن. به نظرش این تغییر کل روند توسعه نرم‌افزار رو زیر و رو می‌کنه؛ چون الان تولید کد انقدر سریع شده که گلوگاه اصلی دیگه «نوشتن کد» نیست، بلکه تست، اعتماد، تجربه واقعی استفاده و تشخیص کیفیت نرم‌افزاره. این مقاله برای دیروزه و خیلی تا به امروز ترند شده https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/ @codehalics | کدهالیک

بچه ها من قراره تو این Organization گیتهاب راجع به کوبرنتیز اون چیزایی که بلدم رو بنویسم ممنون میشم هم کمک کنین دیده شه وهم باهم کانتریبیوت هم داشته باشیم عالی میشه https://github.com/K8S-Academy/Pods @codehalics | کدهالیک

کلود با اسپیس‌ایکس همکاری جدیدی شروع کرده تا ظرفیت پردازشی خودش رو به‌طور جدی افزایش بده. طبق این توافق، کلود قراره از تمام ظرفیت پردازشی دیتاسنتر Colossus 1 استفاده کنه ظرفیتی که بیش از ۳۰۰ مگاوات توان اضافه در اختیارش می‌گذاره همین موضوع باعث شده محدودیت استفاده از Claude Code و Claude API افزایش پیدا کنه از امروز، محدودیت ۵ ساعته Claude Code برای پلن‌های Pro، Max و Team دو برابر می‌شه، محدودیت ساعات شلوغ برای کاربران Pro و Max حذف می‌شه و محدودیت API برای مدل‌های Opus هم به شکل قابل توجهی بالا میره البته حواستون باشه که محدودیت هفتگی همچنان پا بر جاست یعنی اینکه لیمیت هفتگی خیلی سریع تر از قبل پر میشه و مدت بیشتری باید منتظر بمونین ! @codehalics | کدهالیک

یه مثال خیلی خوب برای Bus Factor، خود لینوکسه. از بیرون به‌نظر میاد پروژه خیلی به لینوس توروالدز وابسته‌ست، ولی سوال اینه: چطوری کاری کرد که Bus Factor پروژه عملاً ۱ نمونه؟ یکی از جواب‌های مهمش Git بود. گیت کمک کرد توسعه لینوکس از حالت متمرکز خارج بشه؛ هر maintainer بتونه بخش خودش رو مدیریت کنه، تغییرات از چند لایه review رد بشه، و دانش و مسئولیت بین آدم‌های مختلف پخش بشه. لپ کلام: لینوس فقط آدم مهم پروژه نبود؛ سیستمی ساخت که پروژه بدون قفل شدن روی یک آدم، زنده بمونه. فک نکنم از این قشنگ تر میشد باس فکتور و هندل کردنش توی لینوکس رو توضیح داد دی: #lawsofsoftwareengineering @codehalics | کدهالیک

ادامه قوانین مهندسی نرم افزار ! یه مفهومی توی تیم‌های نرم‌افزاری هست به اسم Bus Factor. خیلی ساده یعنی چند نفر اگر از تیم حذف بشن، پروژه می‌خوابه؟ مثلا اگر فقط یک نفر بلد باشه سیستم پرداخت چطوری کار می‌کنه، فقط یک نفر دیتابیس رو بفهمه، یا فقط یک نفر بدونه دیپلوی چطوری انجام میشه، Bus Factor اون بخش میشه ۱. یعنی تیم عملا روی دانش یک نفر قفل شده و با نبودنش همه‌چیز کند، مبهم یا متوقف میشه. هرچی Bus Factor بالاتر باشه، یعنی دانش بین آدم‌های بیشتری پخش شده و تیم سالم‌تره. راه‌حلش هم خیلی پیچیده نیست: مستندسازی درست، کدریویو، جفت‌کار کردن، چرخوندن مسئولیت‌ها، و اینکه هیچ آدمی تبدیل به تنها مرجع یک بخش حیاتی نشه. تیم خوب فقط با آدم‌های باهوش ساخته نمیشه، با پخش شدن دانش و کم شدن وابستگی‌های خطرناک ساخته میشه. #lawsofsoftwareengineering @codehalics | کدهالیک

نویسنده این مقاله میگه یه نرم‌افزار کوچیک به اسم Nonograph ساخته که رایگانه، متن‌بازه و همه می‌تونن ازش استفاده کنن. خودش حدود ۶۰۰ دلار خرج کرده تا منتشرش کنه، بیشترش هم برای بررسی‌های امنیتی بوده، ولی حالا بدون پول ازش استفاده می‌کنن. حرف اصلیش اینه که همه‌چیز نباید تبدیل به بیزنس و اشتراک ماهانه بشه. میگه خیلی از سایت‌ها و اپ‌ها اول خوب و ساده بودن، ولی بعد کم‌کم خراب شدن: اشتراک، تبلیغ، قابلیت‌های اجباری AI، پلن پولی، قیمت‌های بیشتر و چیزهایی که بیشتر برای جذب سرمایه‌گذار ساخته شدن تا خوشحال کردن کاربرها. میگه پول مهمه، ولی هر پروژه‌ای لازم نیست پول‌ساز باشه. بعضی چیزها می‌تونن فقط از سر علاقه ساخته بشن. مثال می‌زنه که وقتی آدم از علاقه‌اش پول دربیاره، ممکنه اون علاقه کم‌کم تبدیل بشه به کار و فشار و عدد و رقم؛ دیگه برای لذت ساختن نیست، برای رسیدن به فروش و مشتری و سود میشه. https://nonogra.ph/write-some-software-give-it-away-for-free-05-05-2026 @codehalics | کدهالیک

آپاچی یه آپدیت امنیتی مهم برای وب‌سرور خودش منتشر کرده؛ نسخه 2.4.67 که از ۴ می ۲۰۲۶ در دسترس قرار گرفته. این آپدیت برای رفع چند آسیب‌پذیری امنیتی اومده و مهم‌ترینش مربوط به ماژول HTTP/2 هست؛ همون بخشی که اگر روی سرور فعال باشه، ممکنه در نسخه قبلی یعنی 2.4.66 باعث کرش کردن سرویس یا در شرایط خاص حتی اجرای کد از راه دور بشه. به زبان ساده‌تر، اگر کسی سروری با Apache نسخه آسیب‌پذیر داشته باشه و HTTP/2 هم فعال باشه، بهتره این آپدیت رو جدی بگیره. فعلاً گفته شده اکسپلویت عمومی برای این مشکل منتشر نشده، ولی چون Apache روی تعداد خیلی زیادی از سرورها استفاده می‌شه، طبیعی‌ه که جامعه امنیتی سریع نسبت بهش حساس شده. توصیه اصلی هم اینه که تیم‌های فنی، مخصوصاً کسایی که روی نسخه 2.4.66 هستن، وضعیت سرورهاشون رو چک کنن و در صورت نیاز سریع به 2.4.67 آپدیت کنن. اینجور باگ‌ها شاید برای همه مستقیم خطر فوری نسازن، ولی وقتی روی زیرساخت‌های پرتعداد و عمومی باشن، بهتره قبل از اینکه تبدیل به دردسر واقعی بشن، بسته بشن. https://x.com/i/trending/2051638152490848405 @codehalics | کدهالیک

داکر یه آپدیت خیلی باحال این هفته داده داکر از نسخه ۲۹ به بعد برای نصب‌های جدید، به‌صورت پیش‌فرض از containerd image store استفاده می‌کنه. فرقش با روش قدیمی مثل overlay2 اینه که به‌جای storage driverهای کلاسیک، از snapshotterها استفاده می‌کنه. نتیجه‌اش اینه که داکر بهتر می‌تونه ایمیج‌های چندپلتفرمی رو لوکال بسازه و نگه دارد، با SBOM و provenance کار کند، کانتینرهای Wasm را اجرا کند و حتی از snapshotterهای پیشرفته برای lazy pulling یا توزیع peer-to-peer استفاده کند. برای بیشتر کاربرها این تغییر خیلی محسوس نیست و فلوهای معمول داکر تقریباً همون قبلیس. اما یک نکته مهم دارد: containerd image store معمولاً فضای بیشتری از دیسک می‌گیرد، چون لایه‌های ایمیج را هم به‌صورت compressed نگه می‌دارد و هم extract شده. اگر از نسخه‌های قبلی داکر آپدیت کرده باشید، خودکار به این مدل نمیرین و باید دستی در daemon.json فعالش کنید. نکته مهم‌تر اینکه با عوض کردن storage backend، ایمیج‌ها و کانتینرهای قبلی پاک نمی‌شوند، ولی موقتاً مخفی می‌شوند و اگر برگردید به overlay2 دوباره دیده می‌شوند. پس قبل از مهاجرت، مخصوصاً روی محیط‌های حساس، بهتر عه ایمیج‌های مهم را push یا export کنین. https://docs.docker.com/engine/storage/containerd @codehalics | کدهالیک

این مقاله یه نکته جالب راجب این روزای اینترنت رو یادآوری میکنه بهمون که : یه زمانی اینترنت واقعاً شبیه کشف کردن بود. آدم‌ها چیز می‌ساختن چون حوصله‌شون سر رفته بود، چون بامزه بودن، چون تنها بودن، چون یه جنون کوچیک و شخصی داشتن. ویدیوها خام بودن، میم‌ها بی‌هوا ساخته می‌شدن، یوتیوب شلخته و بانمک بود، فیسبوک هنوز قرار نبود همه‌چیز رو به نمایش و رقابت تبدیل کنه. خیلی چیزها بد و خجالت‌آور بودن، ولی واقعی بودن. الان انگار همون اینترنت هست، ولی روحش نیست. همه‌چیز بیش از حد بهینه شده، همه دارن برای الگوریتم اجرا می‌کنن، حتی شوخی‌ها و ویدیوها هم بوی فرمول می‌دن. هوش مصنوعی اینترنت رو نکشت، فقط اومد روی اینترنتی که قبلش آدم‌ها رو عادت داده بود مثل ماشین محتوا تولید کنن. شاید بهترین روزهای اینترنت واقعاً تموم شده باشه. https://muddy.jprs.me/posts/2026-05-03-the-best-is-over/ @codehalics | کدهالیک

یکی اومده باگ copyfail که لینوکس های 2017 به بعد رو دسترسی روت ازشون میگرفت با یک یوزر معمولی رو داخل کانتینر تست کرده مثلا مثل کانینتر های داکر یا پادمن . اکسپلویت داخل کانتینر جواب داده و کاربر را root کرده، اما چون کانتینر rootless بوده، این root شدن فقط داخل همان کانتینر معنی داشته و به root شدن روی سرور اصلی منجر نشده. یعنی rootless بودن کانتینر جلوی فرار کامل از کانتینر به هاست را گرفته https://www.dragonsreach.it/2026/05/04/cve-2026-31431-copy-fail-rootless-containers/ @codehalics | کدهالیک

این پترن‌ها رو همیشه سعی کنید ببینید و یاد بگیرید؛ اینکه یه پروژه بزرگ چطوری تصمیم می‌گیره از یه زبان بره سمت یه زبان دیگه، چطوری مسیرش رو فازبندی می‌کنه، چی رو نگه می‌داره و چی رو عوض می‌کنه، خودش یه کلاس درس کامل از مهندسی نرم‌افزار و مدیریت تغییره. @codehalics | کدهالیک

مثل اینکه Bun قراره کم‌کم با Rust ری‌رایت بشه، ولی هنوز این‌جوری نیست که رسماً و یک‌باره بگن «Zig رفت، Rust اومد». چیزی که فعلاً توی ریپوی گیت‌هابش دیده می‌شه، یه راهنمای مرحله‌ایه برای پورت کردن فایل‌های Zig به Rust. توی Phase A قراره برای هر فایل Zig، یه فایل Rust کنار همون فایل ساخته بشه و منطقش تا جای ممکن همون‌جوری منتقل بشه؛ حتی لازم نیست همون اول کامپایل هم بشه. بعداً توی Phase B میان این کدها رو crate به crate درست و قابل کامپایل می‌کنن. نکته جالبش اینه که Bun نمی‌خواد تبدیل بشه به یه پروژه Rust معمولی. توی داکیومنتش صریح گفته از چیزهایی مثل tokio، hyper، futures، async fn و حتی std::fs و std::net استفاده نکنید. یعنی می‌خوان event loop، مدل async، syscallها و معماری خود Bun حفظ بشه. پس ماجرا بیشتر شبیه یه مهاجرت کنترل‌شده‌ست برای اینکه پروژه پایدارتر، امن‌تر، قابل نگهداری‌تر و برای contributorها قابل‌دسترس‌تر بشه؛ نه اینکه صرفاً چون Rust ترند شده یا سریع‌تره، Zig رو بذارن کنار. https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd5730ef1549e88407701a5 @codehalics | کدهالیک