کدهالیک | codehalic

بعد دو روز کاری بسیار سخت خبر های جذاب تک که کسی سمتشون نمیره و دوسشون نداره رو براتون بازگو میکنم :)))))))))))))) لعنت به هر چی تسک و باگ و فیچر و برنامه نویسیو و کی این کیبوردو داده دست منو و همین چرخ خیاطیو ............... @codehalics | کدهالیک

خلاصه ماجرا اینکه تو سیستم‌های حساس همیشه فرمول طلایی «اول تصاحب کن، بعد انجام بده» (Claim-Then-Act) رو بچسبید؛ حالا بسته به حجم ترافیک پروژه‌تون، چه با بادیگاردیِ سریعِ ردیس دم در، چه با نظمِ صف کافکا، و چه با Unique Constraint دیتابیس به عنوان خط آخر دفاع! 😉👊 @codehalics | کدهالیک

FYI : کلمه SETNX مخفف SET if Not Exist عه. کارش دقیقاً همینه: «تنها در صورتی این کلید رو بساز که از قبل وجود نداشته باشه». در حالت عادی، وقتی تو ردیس می‌نویسی SET key value، اگر کلید از قبل وجود داشته باشه، مقدار جدید روی قبلی اوررایت (Overwrite) می‌شه. اما SETNX این‌طوری نیست: اگر کلید وجود نداشته باشه: اون رو می‌سازه و عدد 1 (یا همان True) برمی‌گردونه. اگر کلید وجود داشته باشه: هیچ کاری نمی‌کنه و عدد 0 (یا همان False) برمی‌گردونه. قدیما توسعه‌دهنده‌ها اول SETNX می‌زدن، بعد تو خط بعدی برای کلید یک زمان انقضا (EXPIRE) می‌ذاشتن تا کلید تا ابد تو حافظه نمونه. اما این کار خطرساز بود! اگر سرور دقیقاً بعد از خط اول کرش می‌کرد، کلید تا ابد می‌موند و سیستم قفل می‌شد (Deadlock). امروزه در ردیس سینیورها از دستور توسعه‌یافته‌ی SET با آپشن‌های اختصاصی استفاده می‌کنند که کل این پروسه را اتمیک می‌کند: SET idempotency_key_123 "processing" NX EX 60 این دستور یعنی: «کلید رو بساز فقط اگر نبود (NX) و بعد از ۶۰ ثانیه منقضیش کن (EX 60)». همه این‌ها در یک میلی‌ثانیه و بدون هیچ فاصله‌ای انجام می‌شه. @codehalics | کدهالیک

حالا هر چی گفتم رو به عنوان خط آخر دفاعی توی کدتون باید در نظر بگیرید یعنی بدترین اتفاق که میوفته آخرین خط ما میشه دیتابیس چرا ؟ چون دیتابیس با اون قفل‌های سخت‌افزاریش عالیه، ولی مثل گاوصندوق ته بانکه؛ درگیر کردن دیتابیس گرونه و نباید بذاریم هر درخواست تکراری اصلاً پاش به اونجا برسه! تو سیستم‌های پرترافیک، ما سپرها رو میاریم جلوتر. راحت‌ترین راهکار ردیس (Redis) و دستور SETNX هست که مثل یه بادیگارد فرز دم در، تو همون رم (RAM) و در کسری از ثانیه قفل رو می‌گیره و اجازه ورود همزمان نمیده (Distributed Lock). راهکار خفن‌تر، معماری‌های مبتنی بر ایونت مثل کافکا یا ربیت‌ام‌کیو هست؛ وقتی کلید پرداخت رو به عنوان Message Key بدیم، کافکا تمام درخواست‌های تکراری رو می‌فرسته تو یک پارتیشن و به صورت کاملاً ترتیبی پردازش می‌کنه؛ اینطوری کلاً صورت‌مسئله‌ی همزمانی از ریشه پاک می‌شه! یه سولوشن جذابِ مهندسی دیگه هم اکتور مدل (Actor Model) هست که هر تراکنش رو مثل یک کارمند با یه «صندوق پستی» اختصاصی می‌بینه که تو هر لحظه فقط و فقط یک نامه (درخواست) رو از صندوقش برمی‌داره و باز می‌کنه. در واقع تو یه معماری تمیز، ردیس سپر اوله، کافکا ترافیک رو تو صف‌های تک‌نفره منظم می‌کنه، و دیتابیس هم با اون Unique Constraint به عنوان خط آخر دفاعی، خیالمون رو کاملاً راحت می‌کنه. @codehalics | کدهالیک

بچه‌ها، شاید بپرسید وقتی دو تا درخواست تو یک نانوثانیه به دیتابیس می‌رسن، دیتابیس چطور جادو می‌کنه که همزمانی (Concurrency) پیش نمیاد؟ راز دیتابیس در دو کلمه خلاصه می‌شه: B-Tree Index و Latches وقتی ما یک ستون رو یونیک می‌کنیم، دیتابیس تو پس‌زمینه یک ساختار درختی (B-Tree) براش می‌سازه. وقتی دو درخواست کاملاً همزمان می‌خوان یک کلید (مثلاً شماره تراکنش) رو تو این درخت ثبت (Insert) کنن، موتور دیتابیس (مثل InnoDB در MySQL) برای اینکه درختش به هم نریزه، از قفل‌های بسیار سبک و فوق‌سریعی در سطح حافظه (RAM) استفاده می‌کنه که بهشون میگن Latch یا Mutex. این قفل‌ها اونقدر پایین‌رده هستن که مستقیماً با دستوراتِ سخت‌افزاریِ CPU (مثل پردازش‌های Compare-And-Swap) کار می‌کنن. یعنی در سطح فیزیکیِ پردازنده، محاله دو تا Thread بتونن همزمان یک خانه از حافظه رو تغییر بدن. درخواست اول با اختلاف یک کلاکِ پردازنده (Clock Cycle) قفل (Latch) رو می‌گیره، کلید رو تو درختِ ایندکس می‌نویسه و قفل رو ول می‌کنه. درخواست دوم که پشت این گیتِ سخت‌افزاری منتظر مونده بود، وقتی وارد می‌شه می‌بینه کلید همون یه لحظه پیش نوشته شده؛ پس عملیاتش رو لغو می‌کنه و خطای Duplicate Key میده!» پس در نهایت اتمیک بودن در دیتابیس یک مفهوم بیشتر سخت افزاریه تا نرم افزاری خیلی اینو تو مصاحبه ها میبینم میپرسن ! به یادتون بسپارید لطفا @codehalics | کدهالیک

چه راهی وجود داره که اسیر این داستان نشیم دقیقا متضاد این عمل رو انجام بدیم که بهش میگن Claim-Then-Act اول تصاحب کن، بعد انجام بده برای حل این مشکل، ما باید قانون بازی رو عوض کنیم. به جای اینکه فقط «نگاه کنیم»، باید تو همون نگاه اول صندلی رو «رزرو و قفل» کنیم. یعنی چی؟ یعنی میایم به سیستم می‌گیم: «اگر صندلی خالیه، تو همون لحظه به اسم من قفلش کن که هیچکس دیگه نتونه حتی بهش نگاه کنه، بعد من میرم پولشو میدم.» تو دنیای کدنویسی، ما مرحله ۱ و ۳ (چک کردن و ذخیره کردن کلید) رو با هم ترکیب می‌کنیم تا تبدیل به یک عملیاتِ واحد و غیرقابل‌تجزیه (Atomic) بشه. روند درست اینطوریه: ۱. درخواست میاد و میگه: کلید رو برای من تو دیتابیس (یا ردیس) ثبت کن. ۲. دیتابیس خودش جلوی تکرار رو می‌گیره. پس درخواست اول با موفقیت کلید رو ثبت می‌کنه (Claim). ۳. درخواست دوم که همزمان رسیده بود، وقتی می‌خواد کلید رو ثبت کنه، دیتابیس بهش ارور میده و میگه: «شرمنده، یکی همین الان اینو گرفت!» و درخواست دوم همونجا دراپ میشه. ۴. حالا فقط درخواست اول که موفق شده کلید رو تصاحب کنه، با خیال راحت میره عملیات پرداخت رو انجام میده (Act). @codehalics | کدهالیک

خب اول از همه یه اصطلاحی داریم که تو این سناریو اتفاق افتاده و بهش میگن Check-Then-Act فرض کنید یک صندلی خالی تو سینما مونده. شما سایت رو باز می‌کنید و می‌بینید صندلی خالیه (مرحله Check). همزمان دوستتون هم با گوشی خودش همون صفحه رو باز می‌کنه و اونم می‌بینه صندلی خالیه. حالا جفتتون با هم دکمه «خرید» رو می‌زنید (مرحله Act). نتیجه چی می‌شه؟ جفتتون پول می‌دید اما فقط یک صندلی وجود داره! توی برنامه‌نویسی به این مشکل میگن Race Condition (شرایط مسابقه). یعنی دو تا درخواست مثل دو تا ماشین مسابقه با هم کورس می‌ذارن و چون سیستم فقط عمل «نگاه کردن» رو انجام داده، گول می‌خوره و به هر دو اجازه میده عملیات رو انجام بدن. تو مثال پرداخت هم دقیقاً همین شد: ۱. درخواست اول می‌پرسه: کلید پرداخت هست؟ سیستم میگه: نه. ۲. درخواست دوم (در همون هزارم ثانیه) می‌پرسه: کلید پرداخت هست؟ سیستم میگه: نه. ۳. حالا هر دو درخواست میرن از حساب کاربر پول کم می‌کنن! (فاجعه دو بار کم شدن پول از حساب کاربر) پس اگر جایی این اصطلاح رو شنیدین از امروز دیگ بلدشین که یه پترن برای پیاده سازی عه که عموما باعث ایجاد ریس کاندیشن میشه و چیز جالبی اصلا اصلا نیست و بهتره ازش هیچ وقت استفاده نکنین ! @codehalics | کدهالیک

کلی راه برای پیاده سازی این سناریو وجود داره ولی دلیلی که مطرحش کردم این بود که چندتا اصطلاح رو امروز باهم دیگه موشکافی کنیم پس در چند پست میخوام اولا این سوال رو بررسی کنم دوما اصطلاحاتشو باهم یاد بگیریم و سوما سولوشن بدم و بعد TradeOff کنیم که کدوم میتونه انتخاب خوبی باشه ! پس با من امروز همراه باشید @codehalics | کدهالیک

یکی از دوستان یه مقاله جدید توی دیتی منتشر کرده پیشنهاد می‌کنم بخونید: https://ditty.ir/posts/expensive-style-recalculations-frontend-performance/731189897047

سوال مصاحبه 👇 فرض کنید برای جلوگیری از اجرای تکراری عملیات پرداخت از Idempotency Key استفاده کرده‌اید. پیاده‌سازی فعلی به این شکل است: 1. بررسی می‌کنیم کلید وجود دارد یا نه 2. اگر وجود نداشت، عملیات پرداخت را انجام می‌دهیم 3. سپس کلید را ذخیره می‌کنیم این طراحی در شرایطی که دو درخواست کاملاً همزمان ارسال شوند چه مشکلی دارد؟ چطور این مشکل را به‌صورت مطمئن حل می‌کنید؟ جواب‌هاتون رو توی کامنت‌ها بنویسید تا عصر جواب میدم منم بهش👇 @codehalics | کدهالیک

چت جی پی تی قابلیت جدیدی به اسم Lockdown Mode معرفی کرده که برای کاربرها و سازمان‌هایی طراحی شده که با داده‌های خیلی حساس سروکار دارن. با فعال شدن این حالت، قابلیت‌هایی مثل وب‌گردی زنده، Deep Research، Agent Mode و دانلود فایل‌ها محدود یا غیرفعال میشن تا خطر نشت اطلاعات و حملات Prompt Injection کمتر بشه. در واقع OpenAI بخشی از امکانات هوش مصنوعی رو فدای امنیت بیشتر کرده تا استفاده از ChatGPT در محیط‌های پرریسک مطمئن‌تر باشه. فعلاً این قابلیت برای مشتریان Enterprise، Edu، Healthcare و Teachers ارائه شده و احتمالاً در آینده در دسترس کاربران بیشتری قرار می‌گیره. https://help.openai.com/en/articles/20001061-lockdown-mode @codehalics | کدهالیک

🦀 توی Rust خبری از inheritance به سبک جاوا و ++C نیست، ولی این به معنی نداشتن راه‌حل برای استفاده مجدد از کد نیست. یه مقاله جالب ۹ تا تکنیک مختلف Rust رو معرفی می‌کنه که با Traitها، Composition، Macroها و Genericها خیلی از کاربردهای ارث‌بری رو پوشش میدن. اگر تازه از دنیای OOP وارد Rust شدین و هنوز دنبال معادل extends می‌گردین، این مقاله دید خوبی میده که چرا Rust مسیر متفاوتی رو انتخاب کرده و چطور همون مشکلات رو حل می‌کنه. ارزش خوندن داره: https://medium.com/@carlmkadie/nine-ways-to-do-inheritance-in-rust-a-language-without-inheritance-14825bf1e215 @codehalics | کدهالیک

دفعه بعد كه خواستيد پاورپوينت درست كنيد، به اين فكر تنيد كه يه لايبررى JS هست كه اكه به Claude بديد، براتون يه يرزنتيشن interactive جالب با كلى transition متنوع درست ميكنه! revealjs.com @codehalics | کدهالیک | Amir

در مقاله ای که میخونین راجب به CAP به عنوان یکی از نیازمندی ها و چالش های فنی پیش از پیاده سازی چت دیوار توجه ویژه ای شده بود که ما قبلا این قانون از مهندسی نرم افزار رو ویژه بررسیش کردیم که خوندن مجددش خالی از لطف نیست ! @codehalics | کدهالیک

برای کسایی که علاقمندن داستان تغییر استک چت دیوار از پایتون به الکسیر رو بخونن پیشنهاد میکنم این مقاله از بلاگ آقای علی رجبی راجب این تغییر استک رو مطالعه کنن https://virgool.io/@alirajabi/%DA%86%D8%AA-%D8%AF%DB%8C%D9%88%D8%A7%D8%B1-%D8%A7%D8%B2-%D9%BE%D8%A7%DB%8C%D8%AA%D9%88%D9%86-%D8%AA%D8%A7-%D8%A7%D9%84%DB%8C%DA%A9%D8%B3%DB%8C%D8%B1-mxeospiy722c @codehalics | کدهالیک

نسخه جدید زبان برنامه‌نویسی الکسیر (نسخه ۱.۲۰) به تازگی منتشر شده است که مهم‌ترین تغییر آن، توانایی تشخیص خودکار خطاهای کدنویسی قبل از اجرای برنامه است. در این آپدیت، الکسیر بدون نیاز به درگیر کردن برنامه‌نویس با کدهای پیچیده، باگ‌ها را پیشاپیش پیدا می‌کند تا نرم‌افزار پایداری بسیار بیشتری داشته باشد. اگر با این زبان آشنایی ندارید، جالب است بدانید که الکسیر برای مدیریت سیستم‌های بسیار شلوغ طراحی شده و به همین دلیل در شبکه‌های مخابراتی کاربرد گسترده‌ای دارد؛ به عنوان یک مثال ملموس، بخش چت اپلیکیشن دیوار نیز با همین زبان نوشته شده تا بتواند همزمان حجم عظیمی از پیام‌های کاربران را در لحظه و بدون قطعی پردازش کند. @codehalics | کدهالیک

چند آسیب‌پذیری مهم در 7-Zip طی ماه‌های اخیر افشا شده که می‌توانند از طریق فایل‌های ZIP دستکاری‌شده، به مهاجم اجازه اجرای کد مخرب روی سیستم قربانی را بدهند. مهم‌ترین این موارد مربوط به نحوه پردازش Symbolic Linkها در فایل‌های ZIP است. مهاجم می‌تواند آرشیوی بسازد که هنگام Extract شدن، فایل‌هایی را خارج از مسیر مورد انتظار بنویسد (Directory Traversal) و در برخی سناریوها این موضوع به Remote Code Execution منجر شود. CVE-2025-11001 و CVE-2025-11002 از شناخته‌شده‌ترین نمونه‌های این دسته هستند. همچنین اخیراً یک آسیب‌پذیری Heap Overflow در Handler مربوط به NTFS Archiveها گزارش شده که حتی باز کردن یک آرشیو آلوده می‌تواند زمینه اجرای کد مخرب را فراهم کند. این مشکل در نسخه 26.00 وجود داشته و در 26.01 برطرف شده است. نکته نگران‌کننده اینجاست که 7-Zip مکانیزم Auto Update ندارد و هنوز تعداد زیادی از سیستم‌ها نسخه‌های قدیمی و آسیب‌پذیر را اجرا می‌کنند. @codehalics | کدهالیک

حمایت از دوره‌های رایگان و باکیفیت فارسی، همیشه جزو ارزش‌های کدهالیک بوده و هست. ✨ دوست خوبمون مرجان عزیزاللهی، به‌تازگی یه دوره جذاب UX Research توی سایت سکان آکادمی منتشر کرده که کاملاً رایگانه و حاصل تجربیات عملی خودشه. دیدن این دوره رو به همه علاقه‌مندان این حوزه پیشنهاد می‌کنیم! لینک دسترسی به دوره: 👇 https://sokanacademy.com/academy/courses/ux-research @codehalics | کدهالیک

من همیشه برای توضیح این خطای مدیریتی یه مثال ساده می‌زنم: به دنیا اومدن یک بچه ۹ ماه زمان می‌بره؛ حالا اگر ۹ نفر رو کنار هم بذاریم، بچه یک‌ماهه به دنیا نمیاد. خیلی وقت‌ها مدیرها با تیم و پروژه هم همین‌طوری برخورد می‌کنن. فکر می‌کنن هر کاری که زمان‌بر شده، با اضافه کردن آدم سریع‌تر می‌شه. در حالی که بعضی کارها ذاتاً زمان، بلوغ، هماهنگی و تمرکز می‌خوان. آدم اضافه کردن، اگر بدون طراحی درست نقش‌ها، مرز مسئولیت‌ها و مسیر تصمیم‌گیری باشه، نه‌تنها کار رو سریع‌تر نمی‌کنه، بلکه تیم رو کندتر هم می‌کنه. چون از یه جایی به بعد، مسئله دیگه «کمبود آدم» نیست؛ مسئله اینه که آدم‌ها دارن وقتشون رو صرف هماهنگ شدن با هم می‌کنن، نه جلو بردن کار. @codehalics | کدهالیک

میدونم که دلتون برای قوانین مهندسی نرم افزار تنگ شده بود (الکی) یه تصور خطرناک توی تیم‌سازی هست که می‌گه: «کار عقب افتاده؟ آدم اضافه کن.» ولی اثر رینگلمان دقیقاً همین‌جا می‌زنه زیر میز. می‌گه هرچی تعداد آدم‌های یک گروه بیشتر می‌شه، الزاماً خروجی بیشتر نمی‌شه؛ حتی گاهی تلاشِ هر نفر کمتر هم می‌شه. نه چون آدم‌ها بدتر می‌شن، نه چون کسی قصد کم‌کاری داره. مسئله اینه که وقتی جمع بزرگ می‌شه، مسئولیت بین آدم‌ها پخش می‌شه، سهم هر نفر کمتر دیده می‌شه، هماهنگی سخت‌تر می‌شه و آدم‌ها ناخودآگاه عقب‌تر می‌ایستن. یه جلسه سه‌نفره رو تصور کن. تقریباً همه حرف می‌زنن، نظر می‌دن، مسئولیت می‌گیرن. حالا همون موضوع رو ببر توی جلسه پونزده‌نفره. چند نفر حرف می‌زنن؟ چند نفر فقط گوش می‌دن؟ چند نفر ته ذهنشون می‌گن «یکی دیگه بالاخره می‌گه»؟ توی تیم فنی هم همین داستانه. همیشه اضافه کردن دولوپر یعنی سرعت بیشتر نیست. گاهی یعنی کانفلیکت بیشتر، مرج بیشتر، جلسه بیشتر، وابستگی بیشتر، منتظر موندن بیشتر. یعنی تیم به جای اینکه انرژی‌اش بره پای ساختن محصول، خرج هماهنگ کردن خودش می‌شه. #lawsofsoftwareengineering @codehalics | کدهالیک