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

۱. دور زدن قفل آدرس‌ها (KASLR)
سیستم‌عامل برای امنیت، جای فایل‌های اصلیش رو توی حافظه مدام تغییر میده که هکرها پیداشون نکنن. اما اینجا نفوذگر اول تونسته اون آدرس مخفی رو پیدا کنه (همون خط اول که نوشته Leaking kaslr).

۲. استفاده از فرصت طلایی (Race Condition)
اون بخش Start racing یعنی هکر از یک ناهماهنگی زمانی توی پردازش‌های سیستم استفاده کرده. یعنی دقیقاً تو یک لحظه خیلی کوتاه که سیستم داشته مجوزها رو بررسی می‌کرده، هکر پریده وسط و کد خودش رو جا کرده.

۳. پر کردن حافظه (Heap Spraying)
نفوذگر اومده بخش Heap حافظه رو با کدهای خودش پر کرده تا شانس اجرای کد مخربش بره بالا. وقتی آدرس حافظه رو گرفت (اون آدرس طولانی که با 0xffff شروع میشه)، یعنی دیگه کنترل سیستم رو کاملاً در دست گرفته.

آخر سر که دستور id رو زده، می‌بینید که نوشته uid=0. این یعنی کاربر معمولی تبدیل شده به Root. حالا این آدم به تمام فایل‌ها و تنظیمات حساس سیستم دسترسی کامل داره، اونم بدون اینکه پسوردی وارد کرده باشه!

این عکس نشون میده که حتی در سال ۲۰۲۶ و نسخه‌های جدید لینوکس، هنوز هم باگ‌های حافظه و پردازش یکی از خطرناک‌ترین راه‌ها برای هک شدن هستن. پس همیشه آپدیت کردن هسته (Kernel) رو جدی بگیرید.

@codehalics | کدهالیک

یه نفر فهمیده کارت صدای خودش به صورت پیش‌فرض SSH روشن داره
یعنی یه دستگاه ساده صوتی عملاً می‌تونه درِ ورود هکرها باشه. نمونه عالی از این‌که IoT چقدر می‌تونه خطرناک باشه.

https://hhh.hn/rodecaster-duo-fw/

@codehalics | کدهالیک

خب امروز میخوام برم ادامه قوانین مهندسی نرم‌افزار رو بگم

راجب یه اصل خیلی مهم و جالب قراره صحبت کنیم که احتمالاً هم تجربه‌ش کردید، هم دیدید تو بقیه

اثر Dunning-Kruger که توسط David Dunning و Justin Kruger معرفی شده، نکتش اینه :
هرچی کمتر بدونی، معمولاً اعتمادبه‌نفست بیشتره!

یعنی وقتی تازه وارد یه حوزه میشی ، چون هنوز عمق ماجرا رو نمی‌بینی، فکر می‌کنی همه‌چیز ساده‌ست و خیلی راحت می‌تونی از پسش بربیای. ولی هرچی جلوتر میری و بیشتر یاد می‌گیری، تازه می‌فهمی چقدر چیز هست که بلد نیستی… و اینجاست که اعتمادبه‌نفست میاد پایین (همون چیزی که بهش میگن valley of despair).

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

از اون طرف، یه پدیده دیگه هم هست به اسم impostor syndrome که توش آدم‌های حرفه‌ای فکر می‌کنن به اندازه کافی خوب نیستن، چون دقیقاً از پیچیدگی‌ها خبر دارن.

#lawsofsoftwareengineering

@codehalics | کدهالیک

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

1- قانون هایروم

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

3- قانون KISS

4- اثر Dunning-Kruger

ضمنا با هشتک #lawsofsoftwareengineering میتونین موارد مرتبط باهاش رو بخونین مثل نظرات و تجربیات شخصی خودم نسبت به هر کدوم
سعی میکنم هر روز یا هر 2 روز یک بار یک قانون جدید رو باهم دیگ بررسی کنیم بنظرم فهمشون خیلی خیلی بهمون دید کلی نسبت به محصول و برنامه نویسی و ... میده !

تمامی این موارد برگرفته از کتابی با همین اسم یعنی lawsofsoftwareengineering عه که سعی میکنم با نثری شیوا ( مثلا من خیلی خفنم ) براتون بیانش کنم
@codehalics | کدهالیک

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

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

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

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

حوصله داشتین مقاله جدید و جذابیه بخونین حتما :

https://techtrenches.dev/p/the-west-forgot-how-to-make-things

@codehalics | کدهالیک

امروز می‌خوام ادامه قوانین مهندسی نرم‌افزار رو ببرم سراغ یکی از خطرناک‌ترین باگ‌های ذهنی که حتی از باگ‌های کد هم بدتره؛ اثر Confirmation Bias یا سوگیری تأییدی. مغز ما دنبال حقیقت نیست، دنبال تأیید چیزیه که از قبل بهش باور داریم. وقتی یه فرض تو ذهنمون شکل می‌گیره (مثلاً مشکل از یه سرویسه)، فقط چیزهایی رو می‌بینیم که همونو تأیید کنه و بقیه نشونه‌ها رو نادیده می‌گیریم یا کم‌اهمیت می‌کنیم. همین باعث میشه تو دیباگ، طراحی سیستم یا تصمیم‌های معماری، مسیر اشتباه رو با اعتمادبه‌نفس بالا ادامه بدیم.

جالب اینجاست که هرچی مطمئن‌تر باشی “مشکل رو فهمیدی”، بیشتر تو این خطایی. چون ذهن دیگه دنبال رد فرضت نیست، فقط دنبال اثباتشه. برای همین آدم‌های باتجربه برعکس عمل می‌کنن؛ به جای اینکه بپرسن «چرا درسته؟» می‌پرسن «چرا ممکنه اشتباه باشه؟» و دنبال داده‌ای می‌گردن که فرضشون رو نقض کنه، نه تأیید. چون تو مهندسی نرم‌افزار، واقعیت به باور ما وفادار نیست، به چیزی وفاداره که واقعاً تو سیستم اتفاق می‌افته.

#lawsofsoftwareengineering
@codehalics | کدهالیک

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

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

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

@codehalics | کدهالیک

تیم TWO-X در حال گسترش است!
در روزهایی که خیلی‌ها مکث کرده‌اند، ما تصمیم گرفته‌ایم ادامه بدهیم. ما هنوز به آینده امیدواریم و باور داریم رشد، همکاری و ساختن، حتی در دل چالش‌ها هم متوقف نمی‌شود.
اگر به دنبال یک محیط حرفه‌ای، پویا و در حال رشد هستی، جای تو کنار ما خالیه.
ما به دنبال افراد باانگیزه و متخصص برای موقعیت‌های زیر هستیم:
🔹 Backend Chapter Lead
🔹 Frontend Developer
🔹 .NET Developer
🔹 Digital Marketing Specialist
🔹 UI/UX Designer
🔹 Senior Product Manager
اینجا فرصتی داری برای کار روی پروژه‌های جدی، یادگیری مداوم و ساختن چیزی که واقعاً اثرگذار است.
اگر فکر می‌کنی این موقعیت‌ها مناسب تو هست — یا کسی رو می‌شناسی که می‌تونه همراه خوبی برای این مسیر باشه — رزومه‌ات رو برامون ارسال کن:

📧 twoxoffice@gmail.com
یا این پست رو به اشتراک بذار.

@codehalics | کدهالیک

Senior Software Engineer (php)

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

https://career.hrcando.ir/co/takhfifan/job-detail/79dcdacb-51ca-4c2a-9190-9a50d7f7fd4b


@codehalics| کدهالیک

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


https://tajrobe.github.io/

@codehalics | کدهالیک

امروز روی مهاجرت داکیومنت API از Swagger به Scalar کار کردم و همزمان مزیت‌های Scalar رو هم بررسی کردم. نسبت به Swagger، یو آی مدرن‌تر و خواناتری داره و در کل developer experience بهتری میده. همچنین performance بهتری روی APIهای بزرگ داره و کار باهاش روان‌تره.

اسکالار یه API playground پیشرفته با تست و لاگ real-time داره و SDKهایی که میده تمیزتر و type-safe ترن. از workflowهای مدرن مثل Git-native بودن و سازگاری بهتر با ابزارهای جدید (مثل AI tooling) هم پشتیبانی می‌کنه؛ یکی از جذاب‌ترین بخش‌هاش هم پشتیبانی نیتیو از MCP بود. از طرفی، نمایش داکیومنت برای end-user ساده‌تره، هر روت URL جدا داره برای share راحت‌تر، و چون از OpenAPI پشتیبانی می‌کنه، سوییچ بین Swagger و Scalar خیلی راحت انجام میشه.

#ابزار_مفید

https://scalar.com/

@codehalics | کدهالیک

خب امروزم قراره بریم به ادامه ی بحث جذاب قوانین مهندسی نرم افزار و قانون هافستدر (Hofstadter)

second t is silent

تلفظ دقیق فارسی : هافس (ساکن) تَ دِ ر

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

این موضوع مستقیم به استیمیت دادن توی Jira ربط داره، چون معمولاً تسک‌ها رو کمتر از واقعیت برآورد می‌کنیم و حتی وقتی سعی می‌کنیم محافظه‌کار باشیم باز هم خطا داریم. به همین خاطر تیم‌ها معمولاً از داده‌های اسپرینت‌های قبلی (velocity) و یه مقدار بافر استفاده می‌کنن تا استیمیت‌ها واقعی‌تر بشه و برنامه‌ریزی قابل اتکاتری داشته باشن.

#lawsofsoftwareengineering

@codehalics | کدهالیک

امروز یکی بهم پیام داد که استاد میخوام بیام برنامه نویسی یاد بگیرم از صفر روزی ۲ ساعت وقت بزارم
آقا نیایید ما خودمونم توش موندیم
بدون اینترنت مگ میشه کار کرد آخه؟
۶۰ روزه کک هیچ کسی نگزید که این اینترنت راه درآمدی ما بود :))))))))

@codehalics | کدهالیک

دعوت به همکاری
موقعیت شغلی : متخصص DevOps
سطح حرفه ای : MID level ‌به بالا
نحوه همکاری : نیمه وقت، پاره وقت
نوع همکاری : حضوری، ریموت، هیبرید

محل کار: تهران - قیطریه
نحوه ارسال رزومه :

پیام در لینکدین، ارسال ایمیل به hosseini@techchi.ir

یا ارسال در بله به شماره 09018013690

@codehalics | کدهالیک

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

در این موقعیت، به دنبال یک Back-End Developer مسلط به C# / .NET هستیم. در این پروژه با موضوعاتی مثل طراحی و توسعه سرویس‌های Back-End، بهبود کارایی، دیباگ سیستم‌های عملیاتی، کار با دیتابیس، Message Broker، و آماده‌سازی سرویس‌ها برای محیط Production درگیر خواهید بود.

مهارت‌های اصلی مورد انتظار:

تسلط به C# و .NET / .NET Core
تجربه طراحی و توسعه RESTful API
تسلط قابل قبول به SQL Server و مفاهیم طراحی دیتابیس
آشنایی با معماری سرویس‌محور یا Microservices
آشنایی با Message Brokerهایی مثل RabbitMQ یا Kafka
آشنایی با Docker و مفاهیم Containerization
آشنایی با Git، CI/CD و فرآیندهای توسعه تیمی
توانایی تحلیل مسئله، دیباگ، مستندسازی و کار مسئولانه روی سیستم‌های Production

موارد زیر مزیت محسوب می‌شود:

تجربه کار با Kubernetes
تجربه در پروژه‌های Telecom ،FinTech یا سیستم‌های پرتراکنش
آشنایی با مفاهیم Observability، Logging، Monitoring و Performance Tuning
تجربه کار با معماری‌های مقیاس‌پذیر و سرویس‌های High-Load

محل کار: تهران، محدوده خیابان مطهری
نوع همکاری: تمام‌وقت
مزایا: ناهار سازمانی، بیمه تکمیلی، هدایای مناسبتی

ارسال رزومه اش توی لینکدینشه باید دایرکت بدید بهش :

لینکدینش

@codehalics | کدهالیک

موقعیت شغلی دلاری برنامه نویس پایتون
لوکیشن: ریموت
ساعات کاری منعطف
سطح زبان :c1 یا بالاتر
رنج حقوق: $4,000 – $2,000

About the Role
We are looking for a skilled Python Developer to join our growing team. In this role, you will design, develop, and maintain high-quality backend systems and applications.


2+ years of experience as a Python Developer or similar role

Strong proficiency in Python

Experience with frameworks like Django, FastAPI, or Flask

Solid understanding of REST APIs and backend development

Experience with databases (PostgreSQL, MySQL, or MongoDB)

Familiarity with Git and version control

Problem-solving mindset and attention to detail

ارسال رزومه :

https://forms.gle/dnNGjbzhdZHpPwku6

سورس آگهی :
لینکدین


@codehalics | کدهالیک

فرصت همکاری: Front-End Developer
شرکت ایزد تک (izad Tech) جهت گسترش تیم فنی خود، به‌دنبال جذب یک توسعه‌دهنده فرانت‌اِند خلاق و مسئولیت‌پذیر است.

نیازمندی‌های کلیدی:
تخصص فنی: تسلط کامل بر Next.js ،TypeScript و Tailwind CSS.

مفاهیم مدرن: درک عمیق از استراتژی‌های رندرینگ (SSG ،SSR ،ISR) و مدیریت State (ترجیحاً Zustand).

ابزارها: تسلط بر Git و آشنایی با Docker و فرآیندهای CI/CD.

کیفیت کد: توانایی نوشتن کد تمیز (Clean Code) و پیاده‌سازی تست‌های خودکار.

مزایای همکاری:
فرهنگ سازمانی باز و شفاف.

تعادل میان کار و زندگی.

کار روی محصولات چالش‌برانگیز در یک تیم حرفه‌ای.

ارسال رزومه:
علاقه‌مندان می‌توانند رزومه خود را به آدرس ایمیل زیر ارسال نمایند:
📧 info@izadtech.ir

@codehalics | کدهالیک

شرکت فراز در حال جذب نیرو برای سه موقعیت شغلی زیر است:

🔹 Senior Frontend Engineer (React.js)
https://jobinja.ir/1470720
🔹 Senior Backend Engineer (Node.js)
https://jobinja.ir/1470431

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

🔹 Talent Acquisition - HR Generalist

اگر حداقل ۲ سال سابقه کاری در حوزه منابع انسانی، به‌ویژه در سطح سازمانی و در زمینه جذب و استخدام دارید، لطفاً رزومه خود را ارسال کنید.

📍 تهران، پونک | حضوری | شنبه تا چهارشنبه ۹–۱۸ (شناوری)

@codehalics | کدهالیک

در رابطه با KISS امروز یه خبر جدید خوندم که تو یه این مقاله یه مهندس نرم افزار راجب اتفاقات درون تیمیش نوشته بود که خیلی بامزه بود و تهشم خیلی دراماتیک تموم میشه و یه طورایی داره راجب همین KISS صحبت میکنه خلاصه اش این بود که:

داستان درباره یه Engineering Managerـه که یه‌دفعه توی جلسه می‌فهمه یه تیم جدید به اسم CX بهش اضافه شده، بدون اینکه ازش نظر بخوان یا حتی خبرش کنن. هدف این تیم این بوده که تجربه مشتری رو بهتر کنه و زمان رسیدگی به تیکت‌ها رو کم کنه. مشکل اینجا بوده که شرکت قبلاً از مدل تیم‌های جدا بر اساس تکنولوژی (مثلاً بک‌اند، فرانت، موبایل) حرکت کرده بود به سمت تیم‌هایی که کل محصول رو end-to-end مالک هستن، ولی این تصمیم جدید دوباره یه جور برگشت به همون مدل قدیمی بود. از طرفی تیم CX هم به‌جای حل مشکل واقعی (وابستگی شدید به دولوپرها برای حل تیکت‌ها)، بیشتر روی ساختن یه داشبورد پیچیده تمرکز کرده بود که عملاً با نیاز بیزینس align نبود.

نویسنده تصمیم می‌گیره مسیر خودش رو بره: به‌جای منتظر موندن برای اون سیستم پیچیده، هر تیم یه داشبورد ساده داخلی بسازه که فقط کارهای ضروری CX رو راه بندازه، و تیم CX رو هم آموزش بدن که خودشون بتونن مشکلات رو حل کنن (self-service). تو اجرا کلی چالش پیش میاد مثلاً دولوپرهای بک‌اند با فرانت‌اند راحت نبودن یا CX اولش از ابزار استفاده نمی‌کرد ولی با ساده‌سازی (مثلاً استفاده از HTML ساده به‌جای React) و آموزش، کم‌کم جا می‌افته. در نهایت زمان حل تیکت‌ها از چند روز می‌رسه به چند ساعت و وابستگی به تیم‌های فنی خیلی کم می‌شه. در عین حال، تیم CX که جدا ساخته شده بود چون عملاً ارزشی ایجاد نکرد، بعد از چند ماه منحل می‌شه. نتیجه کلی اینه که اضافه کردن تیم جدید همیشه راه‌حل نیست و گاهی یه راه‌حل ساده و سریع که درست adopt بشه، خیلی مؤثرتره از یه سیستم ایده‌آل ولی بلااستفاده.

لینک اصلی مقالش اینه
https://learnings.aleixmorgadas.dev/p/adding-a-team-was-the-wrong-strategic

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

@codehalics | کدهالیک

یه مقاله جدید خوندم که نویسنده تو مقاله به یه نکته جالب اشاره می‌کنه: طبق یه تحقیق، آدم‌ها تو سال ۲۰۰۸ روزانه حدود ۳۴ گیگابایت اطلاعات دریافت می‌کردن و این عدد هر سال حدود ۵.۴٪ رشد داشته؛ یعنی اگه ادامه‌ش بدیم، امروز به چیزی حدود ۸۰–۹۰ گیگابایت در روز رسیده! این حجم شامل همه‌چیزه؛ از ویدیو و صدا گرفته تا متن، و حتی کیفیت محتوا هم توش حساب میشه. خلاصه اینکه مغز ما عملاً زیر یه سیل دائمی از اطلاعاته.

بعد نویسنده می‌گه همین فشار باعث اون «brain fog» و افت تمرکز میشه، و برای مقابله باهاش یه راه ساده پیشنهاد می‌کنه: وقتی ذهنت قفل می‌کنه، چند دقیقه بشین و فقط به دیوار خیره شو، بدون فکر و بدون ورودی جدید. به نظرش این کار مثل یه ریست برای مغزه که کمک می‌کنه از این اورلود اطلاعاتی بیای بیرون و تمرکزت برگرده.

لینک اصلی مقاله :
https://www.alexselimov.com/posts/men_who_stare_at_walls/

@codehalics | کدهالیک