امروز دیجیکالا حدود ۲۰۰۰ نفر رو تعدیل کرده ( ۳۰ درصد از نیروهاش ) در توییت جدید آقای طباطبایی این عدد به طور رسمی 200 نفر اعلام شده است یعنی حدود 3 درصد از نیرو های دیجیکالا تعدیل شدن

شاتل حدود ۲۰۰ نفر رو تعدیل کرده ( خبر به طور غیررسمی اعلام شده بر اساس توییت های توییتر )

علی بابا و رقباش هم به احتمال زیاد با تداوم این اتفاقا و بسته موندن پرواز ها کلا فیل بشه ( به طور غیررسمی اعلام شده )

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

با ادامه دار شدنش هم خیلی از این بدتر قراره شاهد موج عظیم از تعدیل باشیم
اینا ترسوندن نیست اینا طبعات تصمیماتیه که راجع به اینترنت گرفته شده و بعید میدونم به قبل از ۹ اسفند اینترنت برگرده

ناامیدم همین اینا ناامیدیای خودمه تو دلتون خالی نمیکنم فقط دعا کنین اینبار که اینترنت وصل بشه من دوست ندارم کسی دیگ بیکار شه با این وضعیت همتون دوستای خوب منین آخه ناراحتیتونو نبینم هیچ وقت! :)

@codehalics | کدهالیک

تا حالا شده توی خونه مبل رو جوری بذاری که جلوی پریز رو بگیره ولی بعد یه مدت به همون وضعیت عادت کنی؟ حالا اگه یکی بیاد مبل رو جابه‌جا کنه که خونه رو قشنگ کنه، شاکی می‌شی چون تمام نظم ذهنی تو به هم ریخته. این دقیقا خلاصه اتفاقیه که بهش می‌گن قانون هایروم.

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

حرف حساب این قانون ساده است: اگه کدی که زدی کاربر زیادی داشته باشه، دیگه مهم نیست توی داکیومنت و راهنما چی نوشتی. مردم به جای اینکه بخونن تو چی گفتی، نگاه می‌کنن کدت در عمل چیکار می‌کنه و دقیقا روی همون رفتار (حتی اگه غلط یا اتفاقی باشه) حساب باز می‌کنن.

یه مثال واقعی و عجیب از دنیای لینوکس:
یه بار مهندس‌های گوگل دیدن توی خروجی لیست فایل‌های لینوکس چندتا فاصله خالی (Space) بیخود وجود داره. اونا هم از روی دلسوزی این اسپیس‌ها رو حذف کردن که خروجی تمیز بشه. به محض منتشر شدن این تغییر، کلی از برنامه‌های دنیا از کار افتاد! چرا؟ چون برنامه‌نویس‌های دیگه کدشون رو جوری نوشته بودن که مثلا می‌گفت: برو کاراکتر شماره ۲۰ رو بردار. اونا از اون فاصله‌های بیخود به عنوان خط‌کش استفاده می‌کردن و با حذف اونا، کل محاسباتشون غلط شد.

یا مثلا یه کتابخونه قدیمی بود که وقتی فضای هارد خیلی زیاد می‌شد، به خاطر باگ، عدد رو منفی نشون می‌داد. بقیه به جای گزارش باگ، توی کدشون نوشتن: اگه عدد منفی بود یعنی فضا خیلی زیاده! حالا اگه سازنده بیاد این باگ رو درست کنه و عدد رو مثبت نشون بده، برنامه تمام اون آدم‌ها می‌ترکه چون فکر می‌کنن فضای هارد تموم شده.

ته داستان اینه که وقتی نرم‌افزارت بزرگ و پرکاربر می‌شه، تو دیگه صاحب ۱۰۰ درصد کدت نیستی. هر حرکت کوچیکی که بزنی، یه جای دنیا یه نفر هست که به اون مدل "تپق" زدن کدت عادت کرده و اگه اصلاحش کنی، زندگیش به هم می‌خوره. توی ابعاد بزرگ، دیگه فرقی بین باگ و ویژگی وجود نداره؛ هر چیزی که کاربر می‌بینه، براش می‌شه قانون.

تا حالا بهش برخوردین ؟ دوست دارم نظرتونو بدونم راجبش !

#lawsofsoftwareengineering

@codehalics | کدهالیک

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

این قانون دقیقاً همینه: توی بازطراحی یا همون Migration سیستم‌ها، نباید فقط به فیچرهای رسمی نگاه کرد.

اما این هایروم کیه؟
هایروم رایت یکی از مهندس‌های ارشد گوگل هست که تخصصش تغییر دادن کدهایی در مقیاس میلیون خطیه. اون موقعی که داشت روی کتابخانه‌های مرکزی گوگل کار می‌کرد، متوجه شد حتی وقتی یه تغییر خیلی ساده و به ظاهر بی‌ضرر مثل حذف یه «فاصله خالی» یا عوض کردن رنگ یه آیکون رو انجام می‌ده، باز هم یه جایی یه چیزی خراب می‌شه.

هایروم به این نتیجه رسید که هر چقدر هم به کاربرها التماس کنی که «فقط به داکیومنت من اعتماد کنید»، باز هم اونا می‌رن و از رفتارهای غیررسمی و جانبی کد تو استفاده می‌کنن. واسه همین این قانون رو گذاشت تا به بقیه هشدار بده: وقتی کدت محبوب شد و آدم‌های زیادی ازش استفاده کردن، دیگه اون کد فقط متعلق به تو نیست و نمی‌تونی به راحتی هر جاش رو که خواستی عوض کنی.

#lawsofsoftwareengineering

@codehalics | کدهالیک

@codehalics | کدهالیک

ما به دنبال دو نیرو SRE و Devops هستیم.

خوشحال میشم رزومه اتون رو تلگرام برام بفرستید: @ImanAbr7777

@codehalics | کدهالیک

اگر خودتون یا دوستانتون جویای کار در پوزیشن های شغلی زیر هستید به ایشون پیام بدید

@N_aprr


-Senior Frontend Developer
-Senior FullStack Developer ( PHP - Vue - React )
-Staff Enginner
-Technical Product Manager (TPM)
-Senior Scrum Master
-Accountant

اینم از طریق جابینجاشون :
https://jobinja.ir/companies/bugloos/jobs/

@codehalics | کدهالیک

این پست درباره «سگارو» عه؛ کسی که هیچ‌کدوم از ما زحماتش برای اینترنت آزاد رو فراموش نمی‌کنیم.
متأسفانه به نظر می‌رسه این روزها تو شرایط سختی قرار گرفته. از اونجایی که خودش هم مشکلی با انتشار شماره کارتش نداره و پذیرای دونیت هست، خواستم این موضوع رو با شما در میون بگذارم.
می‌دونم که این روزها همه‌مون تو فشار و تنگنا هستیم، اما اگر مایل بودید، هر مبلغی – هرچند کوچیک – می‌تونه کمکی باشه تا شاید گره‌ای از کارش باز بشه.
من از طرف بچه‌های «کدهالیک» مبلغی رو برای حمایت ازش واریز کردم.
امیدوارم که خیلی زود حال همه‌مون بهتر بشه :)

لینک اصلی توییت :‌
https://x.com/pari_D_warrior/status/2046599257952505912?s=20

@codehalics | کدهالیک

دو تا پروژه خیلی خوب برای دور زدن فیلترینگ معرفی شده که خیلی محدود بعضی سایت هارو باز میکنه

https://github.com/masterking32/MasterHttpRelayVPN
یکی این پروژه هست که یوتیوب رو مث بنز براتون میاره بالا

و یکی هم این پروژه هست
https://github.com/patterniha/MITM-DomainFronting
که بعضی سرویس های گوگل رو براتون زنده میکنه ( مثل میت و کلندر و ...)

این دو تا پروژه داخل ReadMe اش کاملا توضیح داده که چطوری کانفیگ میشه و چطور میتونید ازش استفاده کنید



@codehalics | کدهالیک

کاری که قطعی ۵۵ روزه اینترنت با اکوسیستم استارتاپی کشور کرد :)))

@codehalics | کدهالیک

🚀 فرصت همکاری ریموت در یک پروژه استارتاپی

در حال توسعه یک پلتفرم در حوزه رزرو خدمات و مارکت‌پلیس آنلاین هستیم و برای گسترش تیم، به دنبال همکاری با افراد متخصص به‌صورت پاره‌وقت و ریموت از ایران هستیم.

🔎 موقعیت‌های مورد نیاز:

• Social Media Manager
• SEO Specialist (On-Page / Off-Page / Technical)
• Web Designer / Developer (آشنا با UI/UX)
• Content Creator (متنی + سناریو ویدیو)
• Video Editor (Reels / YouTube)
• Digital Marketer
• UI/UX Designer
• Flutter Developer
• Backend Developer (ASP.NET Core یا Laravel)

🎯 شرایط همکاری:
• همکاری ریموت
• پاره‌وقت (با امکان تبدیل به همکاری بلندمدت)
• حضور در یک تیم در حال رشد با فضای استارتاپی
• فرصت رشد و مشارکت در توسعه یک محصول واقعی

📩 برای ارتباط و ارسال رزومه:

Telegram ID: @Btlxadmin

اگر این موقعیت مناسب شما نیست، خوشحال می‌شم این پست رو با دوستان‌تون به اشتراک بگذارید 🙏

@codehalics | کدهالیک

چالش‌های معماری در Cursor: مهار نشتی حافظه روی بستر Electron

توسعه ابزارهای مبتنی بر ایجنت‌های هوش مصنوعی روی ساختارهای چندپردازشی مثل الکترون، چالش‌های پرفورمنس سنگینی خلق میکنه. تیم کرسر اخیرا داکیومنت فنیشون رو درباره استراتژی‌های حل مشکل حیاتی Out of Memory (OOM) و کرش‌های انجین V8 منتشر کرده.

مسئله اصلی اینجا درگیری شدید پروسس‌های Renderer به خاطر لود دیتای حجیم ایجنت‌ها و سربار پیام‌های IPC بود. توی مقاله‌ای که آماده کردم، ریزِ راهکارهای مهندسی کرسر رو بررسی کردیم؛ از تکنیک‌های هندل کردن فایل‌های بزرگ (Chunking) و ایزوله‌سازی پروسسِ اکستنشن‌ها، تا روش‌های شکار Memory Leak که در نهایت باعث شد نرخ کرش‌های این ادیتور ۸۰ درصد کاهش پیدا کنه.

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

https://cursor.com/blog/app-stability

@codehalics | کدهالیک

ما توی تیم چیدلی توی گلرنگ ونچرز دنبال یه نفر نیرو بک‌اند و یه نفر نیرو فرانت اند و یه نیرو تستر میگردیم همکاری به صورت هیبرید هست توی تهران.
بک‌اند: php, laravel
فرانت‌اند: react, next
رزومه هاتون رو برام ایمیل کنید همه رزومه ها چک میشه خیالتون راحت :)


hr@chideli.ir

@codehalics | کدهالیک

اوبر سیستم مالی (Ledger) خودش رو روی DynamoDB ساخت در حالی که این سرویس ابری به‌صورت «پرداخت به‌ازای مصرف» کار می‌کنه یعنی برای هر read و write باید پول بدهی؛ با وجود میلیون‌ها تراکنش روزانه هزینه‌ها به‌شدت بالا رفت و در نهایت حدود ۸ میلیون دلار خرج روی دستش گذاشت و اوبر مجبور شد کل سیستم را کنار بگذارد و دوباره بسازد، با این حال نکته عجیب این بود که با وجود این اشتباه بزرگ هیچ‌کس هم اخراج نشد، و درس مهم اینجاست که DynamoDB برای پرداخت خوبه اما برای Ledger که نیاز به دقت و سازگاری کامل دارد انتخاب اشتباهی است.
داستان این اتفاق رو میتونین توی این مقاله بخونین

https://news.alvaroduran.com/p/nobody-got-fired-for-ubers-8-million

@codehalics | کدهالیک

عجیب ترین خبریه که از یه کمپانی بزرگ میشه شنید یکی اینکه چطور ممکنه هیچکس نگفته باشه که این سیستم حسابداری طور که داریم استفاده میکنیم و روزانه 15 میلیون سفر داریم تو کل جهان قراره به ازای هر سفر کلی تراکنش بزنه و این دیتابیس روی aws عه و داره pay as you go کار میکنه و بعد هیشکی تو اون شرکت به اون بزرگی از این تصمیم آگاه نباشه
داخل این مقاله میگه هر کس که جوین اوبر میشد این پروژه دستش میگرفت و میگفت باید ریفکتورش کنیم !! (چقد شبیه ایران ) و بابتش ارتقا شغلی هم میگرفته !
نکته خیلی مهم اینه که تقریبا این جمله که حاجی اینجا ایرانه دیگ از این اتفاقا میوفته واقعا صدق نمیکنه تو کل دنیا تو هر شرکتی با هر اسکیلی رفتار کلی آدما بر همین اساسه که میخوان یه چیزیو بزنن بیارن بالا مخصوصا توی شرکت های بزرگ هم این آفت بزرگ هست که هر کسی میاد طبق سلیقه خودش کد رو متوجه نمیشه میگه خب بریم ریفکتورش کنیم
بنظر درس های بزرگی از این مقاله میشه گرفت حتما وقت کنین یه دور بخونینش
اما نکته بسیار مهمش داشتن post mortem بعد از وقوع هر اتفاقه اینکه یه نفر رو مصبب ندونستن و با این ضرر مالی هیشکیو تعدیل نکردن ( که احتمالا این یکی تو ایران برعکس باشه )
اوبر شهر عجیبیه خلاصه دانلودش نکنید
@codehalics | کدهالیک

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

قانون زاوینسکی

قانون زاویِنسکی میگه: هر برنامه‌ای وقتی موفق میشه، کم‌کم شروع می‌کنه به اضافه کردن فیچرهای جدید، تا جایی که از هدف اصلی خودش فاصله می‌گیره و حتی تبدیل میشه به یه محصول «همه‌فن‌حریف» که هیچ کاری رو واقعاً عالی انجام نمی‌ده. همون چیزی که میگن: Jack of all trades, master of none.

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

این قانون بیشتر برای پروداکت منیجرها مهمه، چون دائماً بین دو فشار گیر می‌کنن: رشد محصول با اضافه کردن قابلیت‌های جدید، یا حفظ سادگی و تمرکز. چالش اصلی اینه که بدونی چی رو نباید اضافه کنی.

پ.ن: البته در بعضی بازارها (به‌خصوص کشورهای در حال توسعه)، سوپر‌اپ شدن خودش یه مزیت رقابتیه. چون یه اپ می‌تونه چندین سرویس رو یکجا جمع کنه؛ مثل تاکسی، غذا، خرید، خدمات پزشکی و… نمونه‌هاش هم توی ایران زیاده.

#lawsofsoftwareengineering

@codehalics | کدهالیک

من یه تعداد پوزیشن فرانت‌اند از کانکشنام دارم که میتونم ریفرتون بدم.
پوزیشن ها مدیور و سنیور هستن.
لطفا اگه در حال حاضر مشغول نیستین و جویای کارید رزومه‌تونو به ایدی تلگرام زیر بفرستید:

@PooriaFaramarzian

@codehalics | کدهالیک

یه پروژه بسیار خفن امروز پیدا کردم
یه مدل جدید از وب‌گردیه که همه‌چیز رو به‌جای متن، به‌صورت تصویرهای ساخته‌شده با هوش مصنوعی نشون می‌ده.
روی هر بخش کلیک کنی، تصویر جدیدی ساخته می‌شه و عمیق‌تر وارد موضوع می‌شی مثل قدم زدن داخل یک
اینترنت تصویری بی‌نهایت.

پ.ن :داخل عکس اگر ببینید بهش گفتم آموزش ربیت mq و خروجیش واقعا جذاب بود مخصوصا برای آموزش و فهم مطالب میتونین ازش کمک بگیرید

https://flipbook.page/

@codehalics | کدهالیک

این مقاله جدید توی همین ماه توسط martin fowler افسانه ای توی بلاگش شیر شده که میگه: سال‌ها بود توی برنامه‌نویسی فقط از «بدهی فنی» حرف می‌زدیم؛ اینکه کدی ننویسیم که بعداً تغییر دادنش سخت بشه. اما حالا با ورود AI، داستان خیلی جدی‌تر شده و فاولر به یه نکته مهم اشاره می‌کنه: ما فقط یه نوع بدهی نداریم.

کنار بدهی فنی، یه «بدهی شناختی» داریم؛ وقتی که تیم کم‌کم درکش از سیستم رو از دست می‌ده و دیگه دقیق نمی‌دونه چی داره می‌سازه. از اون مهم‌تر «بدهی هدف»ه؛ وقتی که اصلاً فراموش می‌کنیم چرا این سیستم ساخته شده و قراره چه مسئله‌ای رو حل کنه. اینا چیزایی نیست که توی کد دیده بشن، ولی اثرشون خیلی عمیق‌تره.

مسئله اینجاست که AI سرعت تولید کد رو بالا برده، اما همزمان فاصله ما با فهم واقعی سیستم رو بیشتر کرده. خطر اونجاست که بدون فکر و بررسی، به خروجی‌ها اعتماد کنیم و کم‌کم کنترل از دستمون خارج بشه.

حرف اصلی اینه: آینده برنامه‌نویسی فقط ساختن نیست؛ بیشتر از همیشه درباره فهمیدن، اعتبارسنجی و قضاوت کردنه. تیم‌هایی که اینو جدی بگیرن، جلوترن.

مقاله اصلی :

https://martinfowler.com/fragments/2026-04-02.html

@codehalics | کدهالیک

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

یادتونه مدرسه وقتی می‌رفتیم، یه سری مسئله رو گام‌به‌گام از روی جواب‌نامه یا کمک می‌خوندیم؟ سریع حل می‌شد، تکلیف انجام می‌شد، ولی واقعاً نمی‌فهمیدیم چی به چیه. معلم هم می‌گفت «این خط رو چرا نوشتی؟» و ما هم یه جوری سعی می‌کردیم وانمود کنیم فهمیدیم، در حالی که فقط دنبال رفع تکلیف بودیم.

الان با LLMها یه همچین حس مشابهی داره شکل می‌گیره. خیلی راحت می‌تونی کد بگیری، فیچر بسازی، حتی تست هم داشته باشی، ولی اگه حواست نباشه، ممکنه فقط داری «حل‌المسئله‌ای کدنویسی» می‌کنی، نه اینکه واقعاً بفهمی چی ساختی.

و دقیقاً همینجاست که اون آدمای قدیمی‌تر این حوزه دارن هشدار میدن: اینکه حواست باشه کدی که وایب کد می‌کنی رو حداقل بخون، بفهم، و کورکورانه بهش اعتماد نکن. چون LLM همیشه اون درک عمیق از بیزینس تو رو نداره، و اگه یه نکته تو پرامپتت جا بمونه یا بد برداشت کنه، ممکنه تصمیمی بده که کل سیستم رو به هم بزنه.

مسئله این نیست که ازش استفاده نکنیم، مسئله اینه که تبدیل نشیم به کسی که فقط خروجی می‌گیره بدون اینکه بفهمه داخلش چه خبره.

@codehalics | کدهالیک

ما دنبال یه Product Designer می‌گردیم که تجربه واقعی از Design System در پروداکشن رو داشته باشه، دقیق باشه و مسئله حل کنه.

پورتفولیو قوی و تسلط به انگلیسی هم لازمه. همکاری از ارمنستانه و اگه الان ایران هستین، شرکت پروسه ویزا رو انجام میده.

ارسال رزومه به: usefkasiri@gmail.com

@codehalics | کدهالیک