انواع مدل‌های رشد تخصصی در دنیای نرم‌افزار
(در دنیای توسعه نرم‌افزار چه شکلی باشم بهتر است)

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

- مدل I-Shaped
فردی با تخصص عمیق در یک حوزه خاص، اما در سایر حوزه‌ها دانشی ندارد ( شاید بهتر است بگوییم، دانش محدود نسبت به سایر حوزه‌ها ).
مثلاً یک برنامه‌نویس فقط در جاوا بسیار حرفه‌ای است، اما از معماری نرم‌افزار یا مدیریت دیتابیس چیزی نمی‌داند.

مزیت: تسلط بالا در یک موضوع
ضعف: ناتوانی در درک یا تعامل با سیستم‌های پیچیده

- مدل Dash-Shaped (Generalist)
فردی که در موضوعات زیادی دانش سطحی دارد، اما در هیچ‌کدام عمیق نیست.
مثل کسی که از همه زبان‌ها و ابزارها کمی بلد است، اما نمی‌تواند در یک پروژه جدی مسئولیت سنگین بر عهده بگیرد.

مزیت: انعطاف‌پذیری بالا
ضعف: نداشتن عمق تخصص

- مدل T-Shaped
ترکیبی از دو مدل قبلی؛ یعنی دانش عمیق در یک زمینه اصلی + دانش سطحی از حوزه‌های مجاور.
به‌عنوان مثال: یک Backend Developer که در طراحی API و دیتابیس متخصص است، اما در UI، DevOps و امنیت هم شناخت اولیه دارد.

مزیت: هم توانایی حل مسائل پیچیده را دارد و هم می‌تواند با تیم‌های مختلف همکاری مؤثر داشته باشد.

ارتباط نوع پروژه با شکل تخصص

در پروژه‌های کوچک که معمولاً یک یا دو نفر مسئولیت چند نقش را بر عهده می‌گیرند، مدل Dash-Shaped مفیدتر است. چون یک نفر باید همزمان کدنویسی کند، تست بنویسد، کمی طراحی UI انجام دهد و حتی کارهای DevOps را هم پوشش دهد.

اما در پروژه‌های بزرگ، مدل‌های I-Shaped و T-Shaped ضروری هستند. چون پروژه پیچیده است، هر حوزه نیازمند متخصص عمیق خودش است، و در عین حال افرادی لازم‌اند که بین تیم‌ها پل بزنند (T-Shaped).

پیشنهاد من این است که ابتدا Dash-Shaped باشید؛ یعنی در ابتدای مسیر کاری، دانش کلی و سطحی از حوزه‌های مختلف به دست آورید تا درک وسیع‌تری از دنیای نرم‌افزار پیدا کنید.

سپس در یک حوزه اصلی عمیق شوید و به‌مرور، شناخت کاربردی خود از سایر حوزه‌ها را تکمیل کنید. این ترکیب شما را به یک متخصص T-Shaped تبدیل می‌کند؛ مدلی ارزشمند که هم در تیم‌های کوچک و هم در پروژه‌های بزرگ می‌تواند اثرگذار و متمایز باشد.

موفق باشید! 🌹

@srfirouzi_channel

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

github.com/google/libphonenumber

@Linuxor

ساختن README همیشه یه کار سخت بوده، کلی زحمت می‌کشیم کد های پروژه رو می‌زنیم اما وقتی می‌رسه به README نمی‌دونیم توش چی بنویسیم‌؟ و جالب اینجاست اگه README خوب نباشه کسی جذبش نمی‌شه و ممکنه کل زحماتمون هدر بره. اینجا کلی README که خوب نوشته شدن رو جمع کرده ازش می تونید برای پروژه های خودتون الگو بگیرید:


github.com/matiassingers/awesome-readme

@Linuxor

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

آقای Robert L. Read یه کتابچه آنلاین درست کرده توش همه این موارد رو گفته

braydie.gitbooks.io/how-to-be-a-programmer/content/en

@Linuxor

اگر میخواین فایل پایتونی، یا هر فایل با پسوندی که میخواین رو سریع از طریق منوی new file ویندوز بسازین، این بکارتون میاد

گرچه که من توی پایچارم فایلی بخوام مستقیما میسازم ولی برای یکسری فایلای بخصوص کارآمده :)

لینک موحتاوا

می‌دونستین HTML یه تگ داره به اسم kbd که باهاش می‌تونید دکمه های کیبرد رو توی متن به خصوص شورتکاتارو نشون بدید؟


@Linuxor

🔹 /bin → User Binaries
اینجا برنامه‌ها و ابزارهای پایه‌ای کاربر (مثل ls, cp, mv, cat) قرار دارن. بدون این پوشه، خیلی از دستورات ضروری لینوکس کار نمی‌کنن.

🔹 /sbin → System Binaries
برنامه‌ها و دستورات مدیریتی سیستم مثل shutdown, reboot, fdisk اینجاست. بیشتر برای ادمین (root) لازمه.

🔹 /etc → Configuration Files
فایل‌های تنظیمات سیستمی و نرم‌افزارها. مثلاً فایل تنظیمات شبکه (/etc/network/interfaces) یا تنظیمات DNS (/etc/resolv.conf).

🔹 /dev → Device Files
هر سخت‌افزار یا وسیله در لینوکس به شکل یک فایل نشون داده می‌شه. مثلاً:

/dev/sda → دیسک سخت

/dev/null → سیاه‌چاله برای داده‌ها 😅


🔹 /proc → Process Information
دایرکتوری مجازی برای نمایش اطلاعات پروسه‌ها و هسته لینوکس. مثلاً /proc/cpuinfo مشخصات CPU رو نشون می‌ده.

🔹 /var → Variable Files
فایل‌هایی که تغییر می‌کنن: مثل لاگ‌ها (/var/log)، فایل‌های کش، صف پرینت، دیتابیس‌های موقت.

🔹 /tmp → Temporary Files
محل فایل‌های موقتی. هر برنامه می‌تونه اینجا فایل بسازه، ولی بعد ریبوت معمولا پاک می‌شه.

🔹 /usr → User System Resources
برنامه‌ها و کتابخونه‌هایی

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

لینک پست


مارو دنبال کنید:🏃‍♂️........👨‍🦼
🔰@Rs_tutorial

🔧 معرفی ابزار YogaDNS
🧠 یه برنامه کاربردی برای ویندوزه که می‌تونه همه‌ی درخواست‌های DNS سیستمت رو کنترل کنه و از مسیر امن عبور بده — بدون اینکه لازم باشه بری تو تنظیمات ویندوز دست ببری!

🛡 چی کار می‌کنه؟
✅ درخواست‌های DNS رو می‌گیره و از طریق پروتکل‌های رمزگذاری‌شده مثل DoH (DNS over HTTPS)، DoT، یا DNSCrypt می‌فرسته.
✅ از لو رفتن آی‌پی واقعی جلوگیری می‌کنه (مخصوصاً موقع استفاده از VPN).
✅ می‌تونی براش قانون بذاری: مثلا بگی دامنه‌های خاص از یه DNS خاص استفاده کنن یا فقط از مسیر VPN برن.
✅ با سرویس‌هایی مثل NextDNS هم سازگاره.

🎮 به درد گیمرا و کاربرای حساس به حریم خصوصی هم می‌خوره — مخصوصاً برای کسایی که می‌خوان جلوی DNS Leak رو بگیرن یا با فیلترینگ بازی‌ها مقابله کنن.


https://www.yogadns.com

آموزش فعالسازی نسخه پرو یوگا دی ان اس با لایسنس قانونی

⭕️ کلاهبرداری پرواربندی (Pig Butchering) خطرناکترین کلاهبرداری این روزهای اینترنت است.

🔹 روایت کامل و گفت‌وگو با «محمد جرجندی» کارشناس جرایم سایبری در قسمت پنجم برنامه «پیگیر»، ایران وایر.

🆔 @Webamoozir

ورژن ها معمولا سه بخشی ان :

<Major>.<Minor>.<Patch>

که تغییرات اصلی و پایه ای بخوان انجام بدن Major رو تغییر می‌دن بخوان مثلا فیچری اضافه کنن Minor رو یه واحد اضافه میکنن و اگه تغییر جزئی باشه مثلا فیکس کردن یه باگ Patch رو تغییر می‌دن.

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

حالا یه شرکتی می‌آد می‌گه من چهار تاییش میکنم چون توی یه ورژن خاص و یکسان ممکنه کانفیگ های متفاوتی بدم. مثلا یه بیلد برای فلان نوع دستگاه یه بیلد برای فلان نوع دستگاه دیگه. ورژن همون ورژنه ولی کانفیگ تغییر کرده اگه عدد Patch رو اضافه کنن سردرگم می‌شن. چون هیچ کدی تو برنامه تغییر نکرده فقط یه سری کانفیگ برای بیلد تغییر کرده که مثلا برای دستگاه های مختلف سازگار باشه.

در واقع اگه کسی از استاندارد semver یا همون سه تایی استفاده کنه فقط سه تای اول مهمه و تغییر بقیش اصولا نباید منجر به تغییر کد یا چیزی شده باشه و باید یکسان باشه.

@Linuxor

تست نوشتن یکی از مهم‌ترین بخش‌های توسعه وب‌سایت و نرم‌افزاره و یکی از معروف‌ترین ابزارها برای وب Playwright هستش که باهاش تست های خودکار برای مرورگر می‌تونید بنویسید زبان‌های برنامه‌نویسی مختلف مثل JavaScript، Python و C#، ساپورت می‌کنه باهاش می‌تونید تست‌های end-to-end بنویسید تست‌های چندصفحه‌ای و حتی سناریوهای همزمان رو به راحتی اجرا کرد. اگه آشنایی با تست نوشتن ندارید این ویدیوی معرفیش رو ببینید و ببینید چطوری به سادگی تست ها نوشته می‌شن و اجرا می‌شن هوش مصنوعی هم داره و خطا هاتون رو فیکس می‌کنه چیز معروفیه اکثرا ازش استفاده می‌کنن و حتی امکان ریکورد کردن زنده هم داره و به صورت زنده هرجایی از صفحه وب کلیک کنید کدش رو براتون می‌نویسه. (ویدیو رو کامل ببینید)

@Linuxor

باز هم یادآوری منباب اینکه اگر مجبور به دادن سفته برای استخدام هستین، چه مواردی رو باید رعایت کنید:
لینک ویدیو



مارو دنبال کنید:👨‍🦯........🚴
🔰@Rs_tutorial

🚨 هشدار CISA: آسیب‌پذیری بحرانی در Sudo 🚨

آسیب‌پذیری جدیدی به فهرست آسیب‌پذیری‌های فعالاً مورد سوءاستفاده (KEV) توسط CISA اضافه شد:

🔹 CVE-2025-32463

امتیاز CVSS: ۹.۳ (بحرانی)
تحت‌تأثیر: تمام نسخه‌های Sudo پیش از 1.9.17p1
پلتفرم‌ها: تمام توزیع‌های لینوکس و سیستم‌های شبه‌یونیکس

طبق گزارش CISA:
دستور Sudo دارای یک نقص است که اجازه می‌دهد قابلیت‌های شخص ثالث بدون بررسی دامنه‌ی کنترل فراخوانی شوند. این آسیب‌پذیری به مهاجم محلی اجازه می‌دهد با استفاده از گزینه sudo -R (chroot) دستورات دلخواه را با سطح دسترسی root اجرا کند—even اگر در لیست sudoers نباشد.

بهره‌برداری تأیید شده در:

✔️ Ubuntu 24.04.1 (نسخه‌های Sudo 1.9.15p5 و 1.9.16p2)
✔️ Fedora 41 Server (Sudo 1.9.15p5)
✔️ سایر توزیع‌ها با هشدار امنیتی: Alpine Linux، Amazon Linux، Debian، Gentoo، Red Hat

بررسی نسخه فعلی:
sudo -V

بروزرسانی فوری:


🔵 Debian / Ubuntu

sudo apt update
sudo apt install --only-upgrade sudo


🔵 RHEL / CentOS

sudo yum update sudo # نسخه‌های قدیمی
sudo dnf upgrade sudo # نسخه‌های جدید


🔵 Fedora

sudo dnf upgrade sudo


⚪️ openSUSE (Leap / Tumbleweed)

sudo zypper refresh
sudo zypper update sudo


⚫️ Gentoo

sudo emerge --sync
sudo emerge --ask --verbose --update sudo


🟣 Alpine Linux

sudo apk update
sudo apk upgrade sudo


💡 توصیه: همه‌ی مدیران لینوکس/یونیکس باید همین حالا سیستم‌های خود را به‌روز کنند.

یه ابزار خوب برای گوشی.

Docker pull gammu/gammu

از USB Debugging میتونید تماس ها ، sms ها و... مدیریت کنید.
- من جهت اتوماسیون پیامک و تماس های دفترم استفاده کردم تا با کمک یه مدل Systam.Voice.to.voice تماس هارو مدیریت کنید. و پروسه هایو اتوماتیک کنم.

- شما میتونید به پنل playsms استفاده کنید و از طریق وب call/sms مدیریت کنید.

ایده و ابزار هاتون کامنت کنید تا ایده هارو گسترش بدیم.

@Mr05_Dev

مدل درست نوشتاری آدرس (URL)

ساختار URL طبق RFC 3986 تعریف شده و در بخش 2.3 تنها مشخص می‌کند چه کاراکترهایی مجاز هستند:

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

در نتیجه، استفاده از خط تیره (-) یا زیرخط (_) مجاز است، اما RFC هیچ سبک خاصی مثل kebab-case یا snake_case را اجباری نکرده است. با این حال، در عمل kebab-case به‌دلیل خوانایی بهتر و سازگاری بیشتر با موتورهای جستجو، به استاندارد رایج‌تری تبدیل شده است.

ایرادات متداول در آدرس‌ها:

1. استفاده از حروف بزرگ — باعث ناسازگاری و تفسیر متفاوت مسیرها می‌شود.
2. استفاده از فاصله — نیاز به encode دارد و خوانایی لینک را پایین می‌آورد.
3. فینگلیش یا ترکیب زبان‌ها — ناهماهنگی زبانی و افت سئو ایجاد می‌کند.
4. کاراکترهای خاص و نامعمول — نیازمند encode و منبع خطا هستند.
5. استفاده از زیرخط (snake_case) — خوانایی کمتر و شناسایی ضعیف‌تر توسط موتورهای جستجو دارد.
6. استفاده از اعداد یا کدهای نامفهوم — مسیر را غیرتوصیفی و گیج‌کننده می‌کند.
7. ترکیب بی‌هدف حروف و اعداد — فهم و نگهداری آدرس را دشوار می‌سازد.
8. مسیرهای بسیار طولانی یا دارای اسلش‌های اضافی — باعث پیچیدگی و خطای روتینگ می‌شود.

نمونه‌های درست:

https://example.com/page
https://example.com/user-profile/settings
https://example.com/{kebab-case}/{sub-address-directories}

نمونه‌های نادرست:

❌ https://example.com/AboutUs
❌ https://example.com/my page
❌ https://example.com/kharid-drel
❌ https://example.com/page@1!
❌ https://example.com/user_profile
❌ https://example.com/x92d1/page
❌ https://example.com/a1b2c3

در نهایت، درست‌نویسی در URL فقط به رعایت قواعد RFC محدود نمی‌شود؛ ممکن است یک آدرس از نظر فنی معتبر باشد، اما از نظر تجربه کاربری یا سئو کاملاً نادرست به حساب آید.

نکته: برخی آدرس‌های سرویس‌ها ممکن است از نظر خوانایی مناسب به نظر نرسند، اما این موضوع معمولاً به دلایل فنی، امنیتی یا نیاز به عملکرد خاص (مثل شناسایی منحصربه‌فرد درخواست‌ها یا جلوگیری از پیش‌بینی مسیرها) به‌صورت عمدی طراحی شده است.(مثل کوتاه کننده های آدرس)

✍🏻 @thealibigdeli_channel

اگر با داده‌های پرنویز سروکار داری مثلاً GPS، سنسورهای ربات، یا داده‌های مالی این طلاست:

این پروژه یه کتاب تعاملی پایتونیه که قدم‌به‌قدم یاد می‌ده چطور با فیلتر کالمن (Kalman Filter) و سایر فیلترهای بیزی (Bayesian Filters) داده‌های پرخطا رو تصحیح و تخمین دقیق بسازی.

فیلتر کالمن چیه؟
یه الگوریتم هوشمنده که داده‌های پرنویز (مثلاً موقعیت از GPS) رو با پیش‌بینی مدل ترکیب می‌کنه تا بهترین تخمین از وضعیت واقعی سیستم بده.

github.com/rlabbe/Kalman-and-Bayesian-Filters-in-Python

@Linuxor