حمایت از دوره‌های رایگان و باکیفیت فارسی، همیشه جزو ارزش‌های کدهالیک بوده و هست. ✨

دوست خوبمون مرجان عزیزاللهی، به‌تازگی یه دوره جذاب UX Research توی سایت سکان آکادمی منتشر کرده که کاملاً رایگانه و حاصل تجربیات عملی خودشه. دیدن این دوره رو به همه علاقه‌مندان این حوزه پیشنهاد می‌کنیم!

لینک دسترسی به دوره:
👇
https://sokanacademy.com/academy/courses/ux-research

پ.ن: بدون vpn باید وارد سایت بشید وگرنه خطای ۵۰۴ میگیرید !

@codehalics | کدهالیک

چند آسیب‌پذیری مهم در 7Zip طی ماه‌های اخیر افشا شده که می‌توانند از طریق فایل‌های 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 برطرف شده است.

نکته نگران‌کننده اینجاست که 7Zip مکانیزم Auto Update ندارد و هنوز تعداد زیادی از سیستم‌ها نسخه‌های قدیمی و آسیب‌پذیر را اجرا می‌کنند.

@codehalics | کدهالیک

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

https://elixir-lang.org/blog/2026/06/03/elixir-v1-20-0-released/

@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 | کدهالیک

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

@codehalics | کدهالیک

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

revealjs.com

@codehalics | کدهالیک | Amir

🦀 توی 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 | کدهالیک

چت جی پی تی قابلیت جدیدی به اسم Lockdown Mode معرفی کرده که برای کاربرها و سازمان‌هایی طراحی شده که با داده‌های خیلی حساس سروکار دارن. با فعال شدن این حالت، قابلیت‌هایی مثل وب‌گردی زنده، Deep Research، Agent Mode و دانلود فایل‌ها محدود یا غیرفعال میشن تا خطر نشت اطلاعات و حملات Prompt Injection کمتر بشه. در واقع OpenAI بخشی از امکانات هوش مصنوعی رو فدای امنیت بیشتر کرده تا استفاده از ChatGPT در محیط‌های پرریسک مطمئن‌تر باشه. فعلاً این قابلیت برای مشتریان Enterprise، Edu، Healthcare و Teachers ارائه شده و احتمالاً در آینده در دسترس کاربران بیشتری قرار می‌گیره.

https://help.openai.com/en/articles/20001061-lockdown-mode

@codehalics | کدهالیک

سوال مصاحبه 👇

فرض کنید برای جلوگیری از اجرای تکراری عملیات پرداخت از Idempotency Key استفاده کرده‌اید.

پیاده‌سازی فعلی به این شکل است:

1. بررسی می‌کنیم کلید وجود دارد یا نه
2. اگر وجود نداشت، عملیات پرداخت را انجام می‌دهیم
3. سپس کلید را ذخیره می‌کنیم

این طراحی در شرایطی که دو درخواست کاملاً همزمان ارسال شوند چه مشکلی دارد؟

چطور این مشکل را به‌صورت مطمئن حل می‌کنید؟

جواب‌هاتون رو توی کامنت همین پست بنویسید تا عصر جواب میدم منم بهش👇

@codehalics | کدهالیک

یکی از دوستان یه مقاله جدید توی دیتی منتشر کرده پیشنهاد می‌کنم بخونید:

https://ditty.ir/posts/expensive-style-recalculations-frontend-performance/731189897047

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

@codehalics | کدهالیک

خب اول از همه یه اصطلاحی داریم که تو این سناریو اتفاق افتاده و بهش میگن Check-Then-Act

فرض کنید یک صندلی خالی تو سینما مونده. شما سایت رو باز می‌کنید و می‌بینید صندلی خالیه (مرحله Check). همزمان دوستتون هم با گوشی خودش همون صفحه رو باز می‌کنه و اونم می‌بینه صندلی خالیه. حالا جفتتون با هم دکمه «خرید» رو می‌زنید (مرحله Act). نتیجه چی می‌شه؟ جفتتون پول می‌دید اما فقط یک صندلی وجود داره!

توی برنامه‌نویسی به این مشکل میگن Race Condition (شرایط مسابقه). یعنی دو تا درخواست مثل دو تا ماشین مسابقه با هم کورس می‌ذارن و چون سیستم فقط عمل «نگاه کردن» رو انجام داده، گول می‌خوره و به هر دو اجازه میده عملیات رو انجام بدن.

تو مثال پرداخت هم دقیقاً همین شد:
۱. درخواست اول می‌پرسه: کلید پرداخت هست؟ سیستم میگه: نه.
۲. درخواست دوم (در همون هزارم ثانیه) می‌پرسه: کلید پرداخت هست؟ سیستم میگه: نه.
۳. حالا هر دو درخواست میرن از حساب کاربر پول کم می‌کنن! (فاجعه دو بار کم شدن پول از حساب کاربر)

پس اگر جایی این اصطلاح رو شنیدین از امروز دیگ بلدشین که یه پترن برای پیاده سازی عه که عموما باعث ایجاد ریس کاندیشن میشه و چیز جالبی اصلا اصلا نیست و بهتره ازش هیچ وقت استفاده نکنین !

@codehalics | کدهالیک

چه راهی وجود داره که اسیر این داستان نشیم دقیقا متضاد این عمل رو انجام بدیم که بهش میگن
Claim-Then-Act
اول تصاحب کن، بعد انجام بده

برای حل این مشکل، ما باید قانون بازی رو عوض کنیم. به جای اینکه فقط «نگاه کنیم»، باید تو همون نگاه اول صندلی رو «رزرو و قفل» کنیم.

یعنی چی؟ یعنی میایم به سیستم می‌گیم: «اگر صندلی خالیه، تو همون لحظه به اسم من قفلش کن که هیچکس دیگه نتونه حتی بهش نگاه کنه، بعد من میرم پولشو میدم.»

تو دنیای کدنویسی، ما مرحله ۱ و ۳ (چک کردن و ذخیره کردن کلید) رو با هم ترکیب می‌کنیم تا تبدیل به یک عملیاتِ واحد و غیرقابل‌تجزیه (Atomic) بشه.

روند درست اینطوریه:
۱. درخواست میاد و میگه: کلید رو برای من تو دیتابیس (یا ردیس) ثبت کن.
۲. دیتابیس خودش جلوی تکرار رو می‌گیره. پس درخواست اول با موفقیت کلید رو ثبت می‌کنه (Claim).
۳. درخواست دوم که همزمان رسیده بود، وقتی می‌خواد کلید رو ثبت کنه، دیتابیس بهش ارور میده و میگه: «شرمنده، یکی همین الان اینو گرفت!» و درخواست دوم همونجا دراپ میشه.
۴. حالا فقط درخواست اول که موفق شده کلید رو تصاحب کنه، با خیال راحت میره عملیات پرداخت رو انجام میده (Act).

@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 | کدهالیک

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

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

@codehalics | کدهالیک

اولین خبر جذاب این md عه که توی ریپو اپل توی گیت هاب منتشر شده
اپل یه قدم جدی‌تر به دنیای کانتینرها نزدیک شده. توی پروژه‌ی جدیدش به اسم container، قابلیتی به نام container machine معرفی کرده که عملاً یه محیط لینوکسی سبک و سریع روی مک می‌سازه؛ چیزی بین کانتینر و VM، اما خیلی یکپارچه‌تر با خود macOS. می‌تونی روی مک کدت رو با IDE خودت ادیت کنی، همون repo و dotfileهات داخل محیط لینوکسی هم در دسترس باشن، بعد build و run رو داخل لینوکس انجام بدی. حتی اگر ایمیجت systemd داشته باشه، می‌تونی سرویس‌هایی مثل PostgreSQL رو واقعی مثل یه ماشین لینوکسی اجرا کنی. جذاب‌ترش اینه که با imageهای استاندارد OCI کار می‌کنه، یعنی از دنیای Docker و رجیستری‌های معمول خیلی دور نیست. خلاصه اپل داره برای دولوپرهای Apple Silicon یه تجربه‌ی بومی‌تر و تمیزتر از توسعه و تست لینوکسی روی مک می‌سازه؛ مخصوصاً برای کسایی که همیشه بین macOS برای کار روزمره و Linux برای اجرا و تست پروژه گیر بودن.

https://github.com/apple/container/blob/main/docs/container-machine.md

@codehalics | کدهالیک

حالا سؤال اصلی اینه: اینی که اپل ساخته رقیب داکره؟ جواب کوتاه: آره، ولی نه دقیقاً اون مدلی که فکر می‌کنیم. Docker فقط یه ابزار اجرای کانتینر نیست؛ یه اکوسیستم کامل از CLI، رجیستری، Dockerfile، Compose، Desktop و کلی ابزار جانبیه. چیزی که اپل ساخته بیشتر داره نقطه‌ضعف اصلی Docker روی مک رو هدف می‌گیره: اینکه macOS ذاتاً لینوکس نیست و کانتینرهای لینوکسی روی مک باید داخل یه ماشین مجازی اجرا بشن. Docker Desktop سال‌ها همین کار رو کرده، ولی همیشه یه لایه نسبتاً سنگین و جدا از خود سیستم‌عامل بوده. اپل حالا داره می‌گه چرا این تجربه مستقیم‌تر، بومی‌تر و هماهنگ‌تر با Apple Silicon نباشه؟ یعنی به جای اینکه برای توسعه لینوکسی روی مک همیشه به یک ابزار ثالث وابسته باشیم، خود macOS یه مسیر رسمی‌تر برای اجرای کانتینرهای لینوکسی بده؛ با ایمیج‌های استاندارد OCI، محیط لینوکسی قابل نگه‌داری، mount شدن فایل‌های مک داخل لینوکس و اجرای سرویس‌هایی مثل PostgreSQL با systemd. پس فعلاً جایگزین کامل Docker نیست، اما جهت حرکتش واضحه: اپل می‌خواد تجربه‌ی container روی مک کمتر شبیه «یه لینوکس چسبیده به مک» باشه و بیشتر شبیه بخشی طبیعی از خود macOS.

@codehalics | کدهالیک

البته با توجه به قیمت دلار و وضعیت جنگ نزدیکترین تجربمون به macos تقریبا 200 میلیون آب میخوره که خیلیم عالی اصلا کجای این ناراحت کنندس اصلا ؟!
@codehalics | کدهالیک