وقتی مدیر بد داری

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

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

چرا React 19 یک نقطه‌ی مهم در تحول این کتابخانه است:
1. کد خواناتر و تمیزتر: با حذف بسیاری از هوک‌های پراستفاده و نیاز کمتر به مدیریت دستی state، ساختار کد ساده‌تر و قابل‌درک‌تر می‌شود.
2. کاهش کدهای تکراری: حجم کدی که می‌نویسید کمتر است، اما قابلیت‌هایی که دریافت می‌کنید بیشتر.
3. بهبود عملکرد: معماری جدید باعث کاهش رندرهای غیرضروری و روان‌تر شدن اجرای برنامه می‌شود.
4. تجربه بهتر برای توسعه‌دهنده: تمرکز شما از مدیریت وضعیت‌های async برداشته می‌شود و می‌توانید روی ساخت قابلیت‌های اصلی تمرکز کنید.

ا React 19 تلاش می‌کند فرایند توسعه را ساده‌تر کند، مخصوصاً در بخش‌هایی مثل مدیریت داده‌های async. هوک جدید use() امکان کار با عملیات‌های async را طبیعی‌تر و ساده‌تر فراهم می‌کند، پیچیدگی کد را کاهش می‌دهد و روند توسعه را کارآمدتر می‌کن

مهارت گوش دادن فعال (Active Listening)

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

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

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

همین یه کار کوچیک می‌تونه کلی از تنش‌ها و سوءتفاهم‌های تیمی رو از بین ببره.

با js ویندوز هم ران کردن

ویندوز 95 روی الکترون

https://github.com/felixrieseberg/windows95/

ایلان ماسک می‌خواد نور خورشید رو کم و زیاد کنه!

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

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

+ یعنی دستکاری مستقیم تعادل حرارتی زمین با فناوری...

باگ امنیتی با الویت (HIGH) برای لاراول...
دوستانی که از لاراول استفاده میکنن باگی در تاریخ 2025-11-12برای پکیج symfony/http-foundation گزارش شده که ریسک امنیتی bypass authorization داره به عبارتی در سمفونی PATH_INFO رو به صورت اشتباه parse میکنه و این باعث شده تو برخی پروژه ها کاربر به مسیر یا اکشنی دسترسی داشته باشه که نباید داشته باشه به طور معمول
جهت رفع این باگ دستور زیر رو بزنید
composer update symfony/http-foundation
یا اینکه کافیه فقط دستور
composer update رو بزنید لاراول به طور پیشفرض نسخه صحیح رو میاره

Nima Hamdi

کدام بهتر است ؟ GraphQL یا Rest ؟

سال‌ها REST استاندارد اصلی ارتباط با API بود اما با ظهور GraphQL قواعد بازی تغییر کرده است
این انتخاب فقط سلیقه‌ای نیست یک تصمیم معماری است که روی سرعت، حجم داده و تجربه‌ی توسعه تأثیر میزاره

چالش‌های REST که GraphQL حل می‌کند
Over-Fetching
در REST معمولاً داده‌های اضافی برمی‌گردند. GraphQL اجازه می‌دهد فقط همان فیلدهای موردنیاز را با حجم کمتر دریافت کنیم و سرعت بیشتر
Under-Fetching
در REST برای یک کامپوننت پیچیده باید چندین درخواست ارسال شود. GraphQL همه‌ی داده‌ها را در یک Query واحد برمی‌گرداند
رفت و برگشت کمتر و منطق ساده تر
چه زمانی از کدام استفاده کنیم؟

- رست: پروژه‌های کوچک و ساده
- گراف: اپلیکیشن‌های پیچیده و موبایل یا زمانی که چند تیم داده‌ها را مصرف می‌کنند


Mojtaba Vahedi

امسال بلک‌فرایدی یه اتفاق ناراحت کننده و کاملاً جدی رقم زد.

اسنپ‌پی تخفیف ۹۰ درصدی گذاشت و در یک چشم‌به‌هم‌زدن هزاران کاربر به سمت وب‌سایت‌های فروشنده‌ها بزرگ و کوچک هجوم بردند.
(وقتی مارکتینگ اهمیتش از مسئولیت‌پذیر بودن نسبت به کاربر خیلی بیشتره).

نتیجه؟ (ناراحتی و سردرگمی)
یک «Human‑Powered DDoS» کامل!


نه رباتی در کار بود، نه بات‌نت… فقط موجی از کاربرهایی که با انگیزهٔ گرفتن تخفیف، عملاً زیرساخت بعضی سایت‌ها رو از نفس انداختند.
این جنس رویداد خیلی جذابه چون از نظر معماری دقیقاً شبیه حمله DDoS رفتار می‌کنه، اما منبعش ۱۰۰٪ واقعی و انسانی‌ست. Traffic spike لحظه‌ای، پر شدن connection pool، فشار روی دیتابیس، خطاهای 503… همه چیز طبق کتاب، فقط با یک تفاوت:
مقصر «هیجان جمعی و از قبل مدیریت نشده!» بود، نه مهاجم سایبری.

این اتفاق دوباره یادمون می‌ندازه که Scalability فقط یک قابلیت اضافه نیست، بلکه باید بخشی از DNA هر سرویس باشد.
از load balancing تا queue management و طراحی درست back‑pressure.

بلک‌فرایدی امسال تخفیف نداد؛ فقط یه درس معماری واقعی داد.

Arshiya Asadi

دعوت به همکاری: کارآموز Backend (Node.js)

سلام،
ما به دنبال یک کارآموز علاقه‌مند و پرانرژی در حوزه‌ی Backend هستیم؛ فردی که مسیر یادگیری Node.js را شروع کرده و می‌خواهد مهارت‌هایش را در یک محیط حرفه‌ای و پروژه‌محور تقویت کند.

ویژگی‌های مورد انتظار:

آشنایی اولیه با Node.js و حداقل یکی از فریم‌ورک‌ها (Express یا NestJS)

آشنایی با مفاهیم API، درخواست/پاسخ، و اصول توسعه سمت سرور

آشنایی پایه با دیتابیس MongoDB

آشنایی با Git و توانایی کار در تیم

انگیزه بالا برای یادگیری، نظم، و پذیرش چالش‌های جدید

آنچه در این دوره تجربه می‌کنید:

مشارکت در پروژه‌های واقعی و کاربردی

دریافت فیدبک و منتورینگ مستمر

یادگیری اصول معماری بک‌اند، طراحی API، امنیت و بهینه‌سازی

امکان همکاری بلندمدت در صورت عملکرد مناسب

📩 در صورت علاقه، لطفاً رزومه خود را ارسال کنید:
[email protected]

منتظر آشنایی با استعدادهای تازه‌نفس و باانگیزه هستیم.

konect.ir

چند ساعت قبل تیم Next.js خبر دادن که یه باگ جدی پیدا شده. در واقع، باگ اصلش توی React عه و Next.js فقط یکی از فریمورک‌هایی هست که تحت تأثیر این مشکل قرار گرفته. اگر تو پروژه‌هاتون از App Router و Server Components استفاده می‌کنین، پروژه‌تون در خطره.
این آسیب‌پذیری از راه دور exploit می‌شه، نیاز به احراز هویت نداره، می‌تونه هر کدی رو روی سرور شما اجرا کنه و هیچ تعامل کاربری هم نمی‌خواد. به همین خاطر هم بالاترین نمره CVSS یعنی ۱۰ رو گرفته. نسخه‌های 15.x و 16.x آسیب‌پذیرن.
سریع‌ترین راه‌حل اینه که اپ رو به یکی از نسخه‌های فیکس‌شده مثل
15.0.5، 15.1.9، 15.2.6، 15.3.6، 15.4.8، 15.5.7 یا 16.0.7
آپدیت کنین.
اما خیلی ساده بگم مشکل چیه:
وقتی React داره از سمت سرور رندر می‌کنه، یک‌سری پیام و داده به کلاینت می‌فرسته. مشکل از جایی شروع می‌شه که وقتی پیام از سمت کلاینت برمی‌گرده، React زیاد سخت‌گیری نمی‌کنه که این پیام دقیقاً چیه و از کجا اومده.
توی این پیام‌ها می‌تونه نوشته شده باشه: فلان Server Action رو با فلان پارامتر اجرا کن.
ری اکت هم بدون بررسی جدی، همین رو به‌عنوان یک درخواست واقعی قبول می‌کنه. Next.js هم تقریباً همین پیام رو بدون تغییر به React پاس می‌ده.
نتیجه‌اش؟
اگر یکی بتونه یک درخواست جعلی بسازه، می‌تونه یک Server Action واقعی روی سرور رو با پارامتر دلخواهش صدا بزنه و React هم اجراش می‌کنه. یعنی عملاً هکر می‌تونه کاری کنه که سرور هر کدی که بخواد اجرا کنه.
پس اجازه ندین این باگ روی پروژه‌تون بمونه.
همین حالا آپدیت کنین.

Naser Faraji

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

نام این بدافزار را Shai Hulud گذاشته‌اند. دلیل این نام‌گذاری این است که مثل یک کرم عمل می‌کند؛ یعنی اگر یک سیستم آلوده شود، خودش را به جاهای دیگر گسترش می‌دهد.

1. روش ورود بدافزار

مهاجمان از یک اشتباه در تنظیمات GitHub Actions، مخصوصاً در بخش pull_request_target سوءاستفاده کرده‌اند.
این تنظیم اشتباه باعث شده که کدهای مخرب بتوانند داخل مسیر CI/CD پروژه‌ها اجرا شوند.

بعد از نفوذ:
• توکن‌های انتشار npm سرقت شده‌اند
• هکرها با همین توکن‌ها، نسخه‌های جدید آلوده از پکیج‌ها را منتشر کرده‌اند
• این آلودگی تا شرکت‌های بزرگی مثل PostHog هم پیش رفته

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

⸻

2. روش اجرای مخفی

در نسخه جدید حمله، یک فایل به نام setup_bun.js استفاده شده است.
بدافزار به‌صورت مخفی:
• Runtime مربوط به Bun را دانلود و نصب می‌کند
• اسکریپت‌های مخرب را با Bun اجرا می‌کند
هدف این کار این است که فعالیت مشکوک به Node.js نسبت داده نشود و شناسایی سخت‌تر شود.

⸻

3. جمع‌آوری اطلاعات حساس

بعد از ورود، بدافزار با ابزارهایی مثل TruffleHog شروع می‌کند به اسکن کل سیستم. دنبال این موارد می‌گردد:
• کلیدهای AWS
• کلیدهای Azure
• توکن‌های GitHub
• توکن‌های npm
• فایل‌های .env
• کلیدهای SSH
• و هر چیزی که شبیه پسورد یا کلید امنیتی باشد

اطلاعات سرقت‌شده:
• سه بار Base64 رمزگذاری می‌شوند
• بعد برای سرور مهاجم ارسال می‌شوند تا شناسایی‌شان سخت‌تر شود

⸻

4. قابلیت تکثیر خودکار

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

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

⸻

5. مرحله تخریب (بدترین بخش ماجرا)

اگر بدافزار نتواند:
• اطلاعات مهم پیدا کند
• یا نتواند خودش را تکثیر کند
و گاهی هم صرفاً برای پاک کردن ردپا، وارد فاز تخریب می‌شود.

در لینوکس و مک:
• تمام فایل‌های قابل نوشتن کاربر را پیدا می‌کند
• ابتدا روی آن‌ها Overwrite انجام می‌دهد تا قابل ریکاوری نباشند
• بعد کل دایرکتوری‌ها را به‌صورت کامل حذف می‌کند

یعنی هم اطلاعات از بین می‌رود، هم امکان بازیابی هم وجود ندارد.

⸻

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

در دنیای توسعه نرم‌افزار، انتخاب فناوری تنها به سرعت و راحتی محدود نمی‌شود. امنیت یکی از حیاتی‌ترین معیارهاست و داده‌های منتشر شده در Exploit-DB تصویر جالبی از میزان آسیب‌پذیری‌های ثبت‌شده در پلتفرم‌های مختلف نشان می‌دهد.
آمار آسیب‌پذیری‌های منتشر شده (بر اساس Exploit-DB)
🔴 PHP
7,851 آسیب‌پذیری
🟠 WordPress
1,433 آسیب‌پذیری
🟡 Python
41 آسیب‌پذیری
🟢 Node.js
3 آسیب‌پذیری
این تفاوت چشمگیر، تنها یک یادآوری است:
انتخاب پلتفرم مناسب می‌تواند نقش مهمی در امنیت محصول و هزینه‌های بلندمدت ایفا کند. هرچقدر تعداد آسیب‌پذیری‌های شناخته‌شده بیشتر باشد، احتمال تهدیدات امنیتی در پروژه‌هایی که به‌صورت نادرست پیاده‌سازی یا ایمن‌سازی شده‌اند افزایش پیدا می‌کند.
در مسیر توسعه، امنیت انتخاب نیست؛ یک ضرورت است.
(منبع: Exploit-DB)

اگر به هر دلیل نمی‌توانید فعلاً از PHP فاصله بگیرید، حتماً از Docker استفاده کنید. استفاده از Docker به شما کمک می‌کند محیط اجرا را ایزوله نگه دارید و احتمال بروز آسیب‌پذیری‌ها و مشکلات زیرساختی را تا حد زیادی کاهش دهید.

Pouya Azaranmehr

گیت ابزاری بسیار مفیده و قابلیت‌هایی هم داره که گاهی ازشون خبر نداریم ولی اگر پیش بیاد بسیار به درد می خورن؛ از جمله bisect برای کشف جایی که باعث یه باگ شده (و کسی که باعث تولید باگ شده). توی این ویدئو در موردش توضیح می دم.


https://youtu.be/V89oD_HgSbE

در مورد این پست، چند تا نکته جالب مطرح شد:

۱- بیشتر بودن آمار لزومن به معنی ناامن بودن نیست:
درست مثل اینکه پراید بیشترین تصادف رو داره، چون تعدادش بیشتره.
و PHP هم اکوسیستمی بزرگ و پرکاربرد داره، پس طبیعیه که باگ‌های بیشتری کشف و ثبت بشه.

۲- اکوسیستم بزرگ‌تر = بلوغ امنیتی بیشتر:
وقتی حمله‌ها زیاد هستن، باگ‌ها زودتر کشف میشن و جامعه سریع‌تر واکنش نشون میده.
این خودش به امنیت بلندمدت کمک میکنه.

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

۴- کم بودن Exploitهای Node.js = ناشناخته بودن؟ نه الزامن.
معماری ماژولار Node و کوچک بودن سطح حمله هسته باعث شده باگ‌های کمتری در خود Node ثبت بشه.
با این حال حمله‌های Node معمولن از مسیر پکیج‌های third-party اتفاق می‌افته. پس ریسک همچنان وجود داره.

نتیجه نهایی بحث:
هیچ زبان یا اکوسیستمی به‌ذات امن یا ناامن نیست. مسئله، مدیریت ریسکه.

اگه PHP کار می‌کنین: روی ایزولیشن (Docker)، سخت‌گیری امنیتی و کنترل افزونه‌ها حساس باشین.

اگر Node کار می‌کنین: وابستگی‌ها، Audit و کم‌کردن پکیج‌ها حیاتیه.

اگر Python کار می‌کنین: به‌خصوص حوزه وب، مراقب پکیج‌ها و تنظیمات باشین.


در نهایت ممنونم بابت نظراتی که دادین

توهم مدیر خوب بودن

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

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

اگر هدف واقعی مدیریت آرامش تیم است، باید مسئولیت اثر تصمیم‌ها را بر عهده گرفت و اختلافات داخلی را گردن نیروها نینداخت.

معرفی پکیج: fuzzy

وقتی کاربر یه اسم یا عبارت رو اشتباه تایپ می‌کنه، جستجو باید همچنان جواب بده (بر اساس نیاز پروژه البته).
اینجاست که fuzzy به درد می‌خوره.

مثال ساده:

import fuzzy from "fuzzy";

const names = ["Alireza", "Sara", "Ali", "Sami"];
const result = fuzzy.filter("Alriza", names);

console.log(result.map(r => r.string)); // ["Alireza"]

چرا جالب و کاربردیه؟
• جستجوی تقریبی بدون پیچیدگی
• مناسب autocomplete یا search bar
• سبک و سریع
• بدون نوشتن الگوریتم پیچیده از صفر

با fuzzy دیگه لازم نیست نگران اشتباه تایپ کاربر باشیم، همیشه نزدیک‌ترین گزینه رو پیدا می‌کنه!