کدهالیک | codehalic

این قانون یه جمله طلایی داره که کرنیگان توی کتابش توی سال 1974(ببین دغدغه ملتو) نوشته که میگه : The clever version might have taken 30 minutes to write, but debugging took 3 hours. Had the code been written clearly, it would’ve taken 45 minutes to write, but only 30 minutes to debug later. @codehalics | کدهالیک

به طور مثال میگه یه روز پا میشی میای همچین کدی مینویسی میگی به به چه چه :

public string GetUserDisplay(User u) =>
     u?.IsActive == true ? (u.Name ?? "").Trim() is var n && n.Length > 0
     ? n + (u.Role > 0 ? $" ({(Role)u.Role})" : "") : "Unknown" : "Inactive";

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

public string GetUserDisplay(User user)
{
    if (user is null || !user.IsActive)
        return "Inactive";

    var name = user.Name?.Trim();

    if (string.IsNullOrEmpty(name))
        return "Unknown";

    if (user.Role > 0)
        return $"{name} ({(Role)user.Role})";

    return name;
}

از نظر عملکرد کاملا مشابه هم دیگس ولی خوانایی این کد کجا اون کجا پس KISS مرد بزرگ ! @codehalics | کدهالیک

خب امروز یکی دیگ از قوانین مهندسی نرم افزار که داره به KISS صحه میزاره رو قراره بررسی کنیم ! قانون کرنیگان می‌گه وقتی کدی رو زیادی پیچیده و هوشمندانه می‌نویسی، بعداً برای پیدا کردن باگ‌هاش چند برابر بیشتر اذیت می‌شی. موقع نوشتن کد، همه‌چیز توی ذهنت واضحه، ولی چند روز یا چند ماه بعد، همون کد می‌تونه برات تبدیل به یه معما بشه. پس بهتره کد رو ساده، خوانا و قابل‌فهم بنویسی؛ چون کدی که راحت فهمیده می‌شه، راحت‌تر هم درست و نگهداری می‌شه. #lawsofsoftwareengineering @codehalics | کدهالیک

اثر سیگموئیدی خیلی ساده می‌گه هر چیزی که یه مدت رشد نمایی و انفجاری داره، بالاخره یه جایی به محدودیت می‌خوره و رشدش کند می‌شه؛ یعنی نمودارش از حالت «همین‌جوری می‌ره بالا» تبدیل می‌شه به یه منحنی S شکل که کم‌کم صاف می‌شه. نویسنده این مقاله می‌گه این حرف درسته، اما مشکل اینجاست که بعضی‌ها ازش یه نتیجه اشتباه می‌گیرن: می‌گن چون هوش مصنوعی هم بالاخره یه روزی کند می‌شه، پس الان لازم نیست خیلی جدی نگران رشد سریعش باشیم. حرف اصلی متن اینه که «کند شدنِ یک روند» حتماً اتفاق می‌افته، ولی هیچ تضمینی نیست که همین الان یا همین یکی دو سال آینده اتفاق بیفته. درباره هوش مصنوعی هم می‌گه اگر کسی ادعا می‌کنه رشد AI قبل از رسیدن به سطح‌های خیلی جدی و خطرناک متوقف می‌شه، باید دقیق توضیح بده چرا؛ مثلاً به خاطر محدودیت دیتاسنتر، داده، هزینه، الگوریتم یا چیزهای واقعی دیگه. صرفاً گفتنِ «همه رشدها آخرش سیگموئیدی می‌شن» کافی نیست، چون ممکنه هوش مصنوعی قبل از اینکه کند بشه، چند سال دیگه هم با همین سرعت جلو بره. https://www.astralcodexten.com/p/the-sigmoids-wont-save-you @codehalics | کدهالیک

با این لایبری که نوشتم به راحتی و بدون بروزر و در یک ثانیه میتونید چلنج آروان رو (همون که مینویسه «در ﺣﺎل اﻧﺘﻘﺎل ﺑﻪ ﺳﺎﯾﺖ ﻣﻮرد ﻧﻈﺮ ﻫﺴﺘﯿﺪ...») که مثلاً برای جلوگیری از کراولر و روبات‌هاست رو دور بزنید. سورس رایگان: https://github.com/NabiKAZ/arvancloud-bypass Source @codehalics | کدهالیک

بهم ریختگی فارسی تو ترمینال #vscode با این درست میشه:

"terminal.integrated.fontFamily": "Cascadia Mono, Vazirmatn FD, Consolas, Courier New, monospace",
"terminal.integrated.gpuAcceleration": "off",
"terminal.integrated.fontSize": 15,
"terminal.integrated.lineHeight": 1.1,

سورس پست @codehalics | کدهالیک

📢 فرصت همکاری ریموت (پروکسی) - Django+React - Node+React شرایط: حداقل ۴ سال سابقه مرتبط، مکالمه انگلیسی عالی، اینترنت پایدار (ترجیحاً خارج از ایران؛ اگر داخل ایران هستید اینترنت ثابت و مطمئن لازمه). حقوق: از ماهی ۲۰۰۰ دلار (پرداخت با USDT) ارسال رزومه: رزومه‌تون رو بفرستید به Yasaman.aboodi@gmail.com فقط لطفاً عنوان موقعیت رو توی Subject ایمیل بنویسید. منتظر رزومه هاتون هستیم. #backend #frontend ➖➖➖➖➖➖➖➖➖➖ 💬 @job_bashe | گروه کار باشه با دسته بندی شغلی 📢 @karbashe_ir | کانال کار باشه

لکسو‌رنک دقیقا برای حل مشکل reorder کردن لیست‌های خیلی بزرگه. مثلا توی جیرا وقتی یه تسک رو drag میکنی بین دوتا تسک دیگه، نمیاد position صد هزار تا رکورد رو آپدیت کنه چون از نظر دیتابیسی فاجعه‌ست. به جاش هر تسک یه rank استرینگی داره که sortable ـه و الگوریتم میتونه همیشه بین دو تا rank یه rank جدید بسازه. مثلا اگه داشته باشیم:

ali_1210
ali_1211

و بخوای یه تسک بین این دوتا بیاد، میتونه یه چیزی مثل ali_1210V تولید کنه که وقتی sort الفبایی انجام بشه دقیقا بین اون دوتا بشینه، بدون اینکه بقیه آیتم‌ها reorder بشن. اصل ایده‌ش اینه که به جای integer sequence از fractional string استفاده میکنه. یعنی همیشه میشه قبل یا بعد یه آیتم یه rank جدید ساخت و فقط همون رکورد آپدیت میشه. برای همین performance روی board های خیلی بزرگ عالی میمونه و drag & drop عملا O(1) میشه. فقط اگر سال‌ها هی بین دو آیتم insert انجام بشه، رشته‌ها ممکنه خیلی بلند بشن و سیستم هر از گاهی یه rebalance انجام بده تا rank ها normalize بشن. @codehalics | کدهالیک

خب بریم من یه مثال مشخص ازش بزنم تسک های جیرا الان همین شکلیه وقتی اولویت یه تسک رو تغییر میدی میاری پایین تر از اون یکی خب خیلی سخته بخوای ۱۰۰ هزارتا تسک ری اردر کنی فاجعه میشه دیتابیست نابود میشه برای همین یه الگوریتمی نوشتن به اسم LexoRank که این کارش اینه که بتونم Fractional String درست کنه که دقیقا در هر لحظه بتونم قبل یا بعد یه چیزی یه استرینگی بزاره که وقتی سورت با حروف الفبا شد بر همون اساس بشینه ! مثلا به طور نمونه فرض کنین یه بوردی توی جیرا دارید به اسم Ali

این پست داره راجب ۳ تا تکنیک برای ری‌اردر کردن لیست حرف می‌زنه: • بدترین مدل: هر آیتم یه عدد ترتیبی می‌گیره (۱،۲،۳،۴،۵). اگه یکی جابجا بشه، مجبوری تقریبا همه آیتم‌های بعدی رو دوباره شماره‌گذاری کنی → O(N) آپدیت، خیلی کند و سنگین. • مدل دوم (وسط): همون عدد ولی با گپ (فاصله). مثلاً به جای ۱،۲،۳،۴،۵ می‌نویسی ۱۰،۲۰،۳۰،۴۰،۵۰. حالا می‌تونی بین ۲۰ و ۳۰ راحت ۲۵ بذاری بدون ری‌اردر همه → بیشتر عملیات O(1). مشکل: آخرش گپ‌ها پر می‌شن و collision پیش میاد، مجبوری یه بار همه رو بازسازی کنی (خراب‌کاری). • مدل سوم (بهترین): به جای عدد از رشته lexico استفاده می‌کنی (a, aa, ab, b, caa و …). همیشه می‌تونی بدون تغییر بقیه آیتم‌ها، یه رشته جدید دقیقاً بین دو تا موجود بسازی. حتی اگه خیلی نزدیک بشن، با طولانی‌تر کردن رشته بازم جا پیدا می‌کنی. تقریبا همیشه O(1) و فوق‌العاده scalable (مثل LexoRank در Jira). سورس این پست از لینکدین پوریا فرامرزی @codehalics | کدهالیک

خب امروز یه آف تاپیک بزارم تو گروه بچه ها میخوام 15 pro max ام رو بفروشم ZAA عه ۲۵۶ گیگ و رنگشم نچرال تیتانیوم عه هلث اش الان شده ۸۹ و سایکل ۳۷۶ عه قیمت نو دستگاهش امروز زدن ۳۲۰ ت من ۱۰۰ ت زیر قیمت نو اش با رجیستری بهتون میدم ۲۲۰ ت (با رجیستری ) گوشی بدون خط و خش و گلس و قاب و پک اصلی تقدیم میشه دست یه آقای برنامه نویس بوده باهاش کاری نمیکرده کلا گوشی دومم بوده این الان بنظرم لازمه دیگ بفروشمش دی: @codehalics | کدهالیک

هر روز اینترنت باز میکنی اینو هک کردیم اونو اکسپلویت کردیم اینور بک دور کشف شد ! این چه وضعشه آقا چارتا خبر دست اول بدرد بخور بدید یکم حالمون تو این بی اینترنتیه خوب شه :))))))) @codehalics | کدهالیک

🚨 یه آسیب‌پذیری خیلی جدی توی Next.js پیدا شده (CVSS 8.6) که نسخه‌های 13.4.13 به بعد، سری 14 و 15، و همینطور 16.0.0 تا 16.2.4 رو درگیر کرده. این باگ از نوع SSRF ـه و مهاجم می‌تونه فقط با یه request ساده و بدون لاگین، به سرویس‌های داخلی، API Keyها، credentialهای cloud و حتی پنل‌های ادمین دسترسی پیدا کنه 😐 گفته میشه الان حدود ۷۹ هزار instance آسیب‌پذیر روی اینترنت وجود داره. البته اپ‌هایی که روی Vercel هستن امن اعلام شدن و بیشتر self-hostedها در خطرن. اگر از Next.js استفاده می‌کنید، سریعاً به نسخه‌های زیر آپدیت کنید: ✅ 15.5.16 ✅ 16.2.5+ https://hadrian.io/blog/next-js-websocket-ssrf-unauthenticated-access-to-internal-resources-cve-2026-44578-2 @codehalics | کدهالیک

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

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

بیش از دو ماهه که اینترنت توی ایران قطع شده. توی این شرایط سخت، برنامه‌نویس ها، DevOpsها و هر کسی که به ریپوها و میرورهای Docker, Linux, NPM, Golang, Python, Java و ... نیاز داره، واقعاً به مشکل خورده. برای همین ما پروژه «میراوا» رو ساختیم. این پروژه یک لیست از ریپوزیتوری‌ها و میرورهای داخلی و قابل دسترس هست که تو این وضعیت کمک می‌کنه بهمون شما می‌تونین توی سایت، راحت سرچ کنین مثلاً ریپو برای Kali Linux رو جست‌وجو می‌کنین و دقیقاً می‌بینین که کدوم ریپو فعال هست، کدوم در دسترسه و به راحتی به منابع مورد نیازتون دست پیدا می‌کنین. سایت پروژه: https://miravaorg.ir/ کانال اطلاع رسانی میراوا: https://t.me/miravaorg گیت‌هاب: https://github.com/MiravaOrg/Mirava @TehranLUG

چهار مدل این سوال در مصاحبه ها همیشه پرسیده میشه من توی 4 تیپ آوردمش جواب این سوال با جواب سوالای پایین تقریبا یکیه فرض کن در یک موقعیت کاری، نسبت به درست بودن یک تصمیم یا راه‌حل اطمینان داری، اما مدیر یا فرد بالادستی‌ات نظر متفاوتی دارد و روی تصمیم خودش پافشاری می‌کند. در چنین شرایطی چطور رفتار می‌کنی؟ فرض کن توی تیم، تو مطمئنی یک راه‌حل درست‌تره، ولی مدیرت یا کسی که از تو ارشدتره میگه نه، نظر من درسته. تو توی این موقعیت چطور برخورد می‌کنی؟ اگر در محیط کار با موقعیتی مواجه شوی که بر اساس دانش، تجربه یا داده‌هایی که داری، فکر می‌کنی یک تصمیم درست نیست، اما مدیر یا فرد بالادستی‌ات با تو مخالف است، چطور موضوع را مطرح و مدیریت می‌کنی؟ فرض کن مطمئنی تصمیمی که تیم یا مدیرت گرفته اشتباهه و ممکنه به محصول یا پروژه آسیب بزنه، اما مدیرت نظر تو رو قبول نداره. چطور مخالفتت رو بیان می‌کنی و اگر در نهایت تصمیم مدیر اجرا شد، چه رفتاری نشون می‌دی؟ پس در نهایت دوست دارم نظرتونو بدونم ! بعد امشب راجبش صحبت میکنیم حتما حتی اگر نظری ندادید من نظر و تجربه شخصیم توی جواب این سوال رو میگم @codehalics | کدهالیک

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

راهکار چیه حالا : برای کم کردن این خطا باید عمداً خلاف حدس خودمان را هم بررسی کنیم. یعنی وقتی نظری داریم، از خودمان بپرسیم: «اگر اشتباه کنم، چه نشانه‌ای باید ببینم؟» در تصمیم‌های تیمی هم بهتر است فقط دنبال تأیید نظر جمع نباشیم؛ مثلاً اگر همه فکر می‌کنند یک تکنولوژی بهترین انتخاب است، یک نفر مأمور شود دیدگاه مخالف را بررسی کند. تست‌های خودکار، معیارهای عملکردی، آزمایش، A/B تست و کد ریویو با نگاه تازه کمک می‌کنند تصمیم‌ها کمتر بر اساس حس و تعصب باشند و بیشتر روی شواهد واقعی بنا شوند. @codehalics | کدهالیک

خب پس بریم ادامه قوانین مهندسی نرم افزار سوگیری تأییدی یعنی ذهن ما معمولاً دنبال چیزهایی می‌گردد که حرف، حدس یا باور قبلی‌مان را تأیید کند؛ نه چیزهایی که آن را به چالش بکشد. مثلا وقتی یک برنامه‌نویس فکر می‌کند باگ از ماژول A است، ممکن است فقط همان بخش را زیر و رو کند و خطاهای ماژول B را نبیند، چون از قبل تصمیم گرفته «مشکل آنجاست». این اتفاق در کد ریویو هم می‌افتد؛ اگر به یک نفر اعتماد زیادی داشته باشیم، شاید کدش را سطحی‌تر ببینیم، یا اگر از یک نیروی junior انتظار خطا داشته باشیم، ممکن است چیزهای کم‌اهمیت را جدی تلقی کنیم. #lawsofsoftwareengineering @codehalics | کدهالیک