چنل شخصی سید رحیم فیروزی

آماتور در مقابل مبتدی
(چرا آماتور بودن به معنای تازه‌کار بودن نیست؟)

یکی از اشتباهات رایج، یکسان دانستن «آماتور» و «مبتدی» است؛ در حالی که این دو واژه مفاهیم متفاوتی دارند.

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

اما آماتور (Amateur) به معنای مبتدی نیست. آماتور کسی است که از روی علاقه و اشتیاق در یک زمینه فعالیت می‌کند، نه لزوماً به عنوان شغل. ممکن است یک آماتور سال‌ها مطالعه کرده باشد، پروژه‌های متعددی انجام داده باشد و دانش و مهارتی بالاتر از بسیاری از افراد شاغل در همان حوزه داشته باشد.

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

در مقابل، حرفه‌ای (Professional) به فردی گفته می‌شود که فعالیت خود را با مسئولیت، تعهد و استانداردهای مشخص انجام می‌دهد؛ معمولاً به عنوان شغل یا وظیفه. حرفه‌ای بودن الزاماً به معنای دانش بیشتر نیست؛ همان‌طور که آماتور بودن نیز به معنای دانش کمتر نیست.

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

انتخاب درست واژه‌ها، به درک بهتر مفاهیم کمک می‌کند.

موفق باشید! 🌹

@srfirouzi_channel

سلام،

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

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

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

امیدوارم این مطالب تا امروز برای شما مفید بوده باشند و در ادامه نیز بتوانم محتوای ارزشمندتری منتشر کنم.

🌹 موفق باشید!
@srfirouzi_channel

دانش لایه‌ای: پیش‌نیاز پنهان در درک عمیق
( چرا فهم عمیق در توسعهٔ نرم‌افزار به پیش‌نیازهای نظری وابسته است؟ )

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

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

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

دانش به‌صورت لایه‌لایه ساخته می‌شود:

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

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

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

بنابراین اگر متنی را به‌خوبی درک نمی‌کنیم، لزوماً مسئله از متن نیست؛ ممکن است بخشی از زیرساخت دانشی آن هنوز در ذهن ما ساخته نشده باشد.

فهم عمیق حاصل تلاقی «دانش پیشین» و «مطالعهٔ هدفمند» است؛
و تجربه زمانی بیشترین اثر را دارد که بر بستری از فهم نظری استوار شده باشد.

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

🌹 موفق باشید!

@srfirouzi_channel

سه‌گانهٔ تصمیم‌گیری در فلسفهٔ کنش
(از Omission vs. Commission تا تصمیم‌های آگاهانه در توسعهٔ نرم‌افزار)

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

در مباحث مربوط به Omission vs. Commission، تصمیم صرفاً «عمل کردن» نیست؛ گاهی تصمیم اصلی در عدم مداخلهٔ آگاهانه نهفته است. البته این رویکرد برای همهٔ موقعیت‌ها مناسب نیست، اما در شرایط خاص می‌تواند دقیق‌ترین و منطقی‌ترین شکل تصمیم‌گیری باشد.

سه گزینه‌ای که بررسی کردیم چنین بودند:

۱) روندی در حال وقوع است، اما هیچ تصمیمی دربارهٔ آن نمی‌گیریم.
۲) تصمیم می‌گیریم روند را تغییر دهیم.
۳) تصمیم می‌گیریم روند به‌صورت طبیعی و بدون مداخله، ادامه یابد.

گزینهٔ اول نوعی بی‌تفاوتی یا رهاشدگی است.
اما گزینهٔ سوم یک انتخاب آگاهانه است؛ یعنی وضعیتی که در فلسفهٔ کنش، «عدم مداخلهٔ انتخاب‌شده» تلقی می‌شود.

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

- مسئلهٔ واقعی وجود ندارد،
- یا اثر عملی خطا ناچیز است،
- یا رفتار کاملاً مطابق طراحی است.
- هزینه تغییر بیشتر از اهمیت ادامه خطاست

در این وضعیت نیز سه انتخاب پیشِ‌رو داریم:
بی‌تصمیمی، تغییر وضعیت، یا ادامهٔ آگاهانهٔ روند فعلی.

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

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

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

موفق باشید! 🌹

@srfirouzi_channel

تراز حافظه و پدینگ در گولنگ
(مدیریت حافظه با ورود جزیی به جرییات مدیریت حافظه در گولنگ)

در گولنگ، دو مفهوم struct padding و alignment نقش تعیین‌کننده‌ای در نحوه‌ی قرارگیری فیلدهای یک struct در حافظه دارند. هر نوع داده یک سایز طبیعی دارد که معمولاً بر پایه‌ی توان‌های ۲ تعریف می‌شود (۱، ۲، ۴، ۸ و ...). همچنین اندازه‌ی بهینه برای دسترسی پردازنده معمولاً با word size معماری هماهنگ است؛ برای مثال، در معماری ۶۴ بیتی، دسترسی‌های هم‌تراز با ۶۴ بیت برای پردازنده کارآمدترند.

نکته‌ی اصلی اینجاست که تراز کردن داده‌ها وظیفه‌ی کامپایلر (و در سطح پایین‌تر، قوانین ABI و معماری سخت‌افزار) است. پردازنده در صورت تراز بودن داده، با دستورالعمل‌های کمتر و هزینه‌ی کمتری به آن دسترسی پیدا می‌کند؛ در غیر این صورت ممکن است نیاز به چندین عملیات بارگذاری و ترکیب داده باشد. از همین رو، انواع داده در اغلب زبان‌ها ،از جمله گولنگ، دارای اندازه‌ها و در استراکچر دارای alignmentهایی هستند؛ این الگو مستقیماً از طراحی سخت‌افزار ناشی می‌شود.طبیعتا فضای مابین مقادیر داده‌ها (padding) فضای از دست رفته هستند

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

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

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

موفق باشید! 🌹

@srfirouzi_channel

وقتی گولنگ را با ژاپن فئودال مقایسه می‌کنیم…

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

- Goroutine — سامورایی‌های سبک‌وزن
جنگاورانی چابک که ده‌ها مأموریت را هم‌زمان اجرا می‌کنند.

- Channels — جاده‌های پیک‌رسان رسمی شوگون
مسیرهای امنی که پیام‌ها بدون هرج‌ومرج از آن عبور می‌کنند.

- Scheduler — دایمیوی حکمران سایه
فرمانده‌ای پنهان که سامورایی‌ها را میان میدان‌های جنگ مدیریت می‌کند.

- Garbage Collector — راهبان پاکسازی پس از نبرد
هر باقیماندهٔ اضافی و رهاشده را آرام و بی‌صدا جمع می‌کنند.

- Go Modules — دفتر ثبت خاندان‌ها و پیمان‌ها
نگهبان نظم، وابستگی‌ها و نسخه‌پذیری قلمرو.

- Interfaceها — مکتب‌های جنگاوری
رفتار تعریف می‌شود، نه ظاهر یا ساختار.

- Structها — زره‌های فولادی سفارشی
ساده، مستحکم و بدون تزئینات غیرضروری.

- Packageها — قلمروهای کوچک شوگون‌سالاری
هرکدام تخصص خود را دارند؛ با هم امپراتوری Go را می‌سازند.

- Error Handling — سندهای رسمی هشدار
اعلام دقیق و محترمانهٔ اینکه چه خطایی رخ داده است.

- Net/HTTP — پیک‌سوار سریع
پیک‌هایی که پیام‌ها را بین قلعه‌ها منتقل می‌کنند.

- Context — فرمان لغو شوگون
با صدور آن، همهٔ واحدهای وابسته باید فوراً عملیات را پایان دهند.

- Testing — دوئل‌های تمرینی سامورایی‌ها
آشکار کردن ضعف‌ها پیش از نبرد اصلی.

- Build System — کورهٔ ساخت سلاح
فولاد خام (کد) را به شمشیر آمادهٔ جنگ (باینری) تبدیل می‌کند.

- Cross-Compilation — آهنگر چندقبیله‌ای
سلاح‌هایی می‌سازد که در هر اقلیم و معماری قابل‌استفاده باشند.

- Standard Library — انبار سلاح‌های سلطنتی
همهٔ ابزارهای پایه، از پیش موجود و قابل اتکاست.

- Sync و Mutex — درهای مهر و موم‌شدهٔ قلعه‌ها
فقط یک نفر حق ورود دارد؛ جلوگیری از هرج‌ومرج منابع.

- Map — طومارهای اطلاعاتی شوگون
دسترسی سریع به موقعیت‌ها و داده‌های حساس.

- Slice — زره‌های قابل‌گسترش
با نیاز جنگجو رشد می‌کند بدون ساخت دوباره.

- Compiler — استاد شمشیرساز امپراتوری
تیزبین، سریع و سخت‌گیر؛ محصول نهایی باید بی‌نقص باشد.

- go philosophy — راه ذِن مبارز
سادگی، تمرکز، حذف اضافات و احترام به کارکرد؛ روح حقیقی سامورایی.

راه، در گام برداشتن آشکار می‌شود. 🌹

@srfirouzi_channel

استفاده نکردن از دانش عکاسی
(تناقض در امکان انجام کار با کیفیت و انجام ندادن آن)

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

پاسخم روشن بود:

«از آن دانش استفاده نمی‌کنم؛ نه به این دلیل که نمی‌توانم، چون برای چنین موضوعی اهمیتی قائل نیستم.»

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

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

بی‌اهمیت دانستن برخی موضوعات، گاهی یک انتخاب آگاهانه و شکل ساده‌سازی است (شاید ساده‌انگاری است)؛ اما گاهی این بی‌تفاوتی به یک الگوی تکراری تبدیل می‌شود. شبیه فردی که می‌داند رفتارش کاملاً درست نیست، اما آن را ادامه می‌دهد؛ نه از سر ناتوانی، بلکه از روی عادت.

این نوع بی‌تفاوتی را نمی‌توان «اعتیاد» نامید، اما می‌توان گفت شباهتی به یک رفتار تثبیت‌شده دارد؛ رفتاری که پیامدهایش را می‌دانیم، اما ذهن آن را به‌عنوان مسیر کم‌تنش‌تر ترجیح می‌دهد.

در نهایت، این یک تناقض آشنا در رفتار انسان است:
می‌توانیم کاری را در بالاترین کیفیت انجام دهیم، اما همیشه تمایلی نداریم همان کیفیت را به کار ببریم.

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

موفق باشید! 🌹

@srfirouzi_channel

مسیر‌های رهایی از cgo در گولنگ
(بازنویسی به گولنگ، WebAssembly ، FFI و wrapper )

بسیاری از توسعه‌دهندگان گولنگ تلاش می‌کنند وابستگی به cgo را کاهش دهند؛ زیرا cgo روند ساخت را سنگین می‌کند، کراس‌کامپایل را پیچیده می‌سازد و پروژه را به toolchain های خارجی وابسته می‌کند. امروزه چهار مسیر عملی برای عبور از این محدودیت وجود دارد:

۱- ترجمهٔ یا بازنویسی کد به Go
رویکردی که کتابخانهٔ modernc.org/sqlite دنبال کرده، روش ترجمهٔ SQLite به Go است تا موتور پایگاه‌داده کاملاً به‌صورت pure Go اجرا شود. این مسیر باعث می‌شود کامپایل بدون نیاز به ابزارهای خارجی و کراس‌کامپایل به‌سادگی انجام شود.
https://modernc.org/sqlite

۲- اجرای کتابخانهٔ در محیط WebAssembly
رویکرد پروژهٔ ncruces/go-sqlite3 این است که کتابخانه که پیشتر به WebAssembly کامپایل شده را در یک محیط اجرای Wasm اجرا می‌کند و کد Go تنها یک لایهٔ ارتباطی سبک ارائه می‌دهد. این روش امنیت بالا، پورت‌پذیری خوب و حذف کامل cgo را به همراه دارد. استفاده از کتابخانه معروف wazero این مسیر را بسیار هموار کرده است
https://github.com/ncruces/go-sqlite3

۳- فراخوانی مستقیم توابع C با FFI، بدون نیاز به cgo
کتابخانهٔ purego با فراهم‌کردن یک FFI سبک، امکان فراخوانی توابع C را بدون استفاده از cgo و با بارگذاری پویا در زمان اجرا فراهم می‌سازد. این رویکرد وابستگی به toolchain های C را حذف و پیچیدگی ساخت را کاهش می‌دهد. به این نکته کوچک هم باید اشاره کرد که کتابخانه استاندارد گولنگ پیشتر فقط برای ویندوز این روش را پیاده سازی و کتابخانه‌های جانبی زیادی از این روش بهره برده‌اند.
https://github.com/ebitengine/purego

4- استفاده از Wrapper اجرایی (External Process Wrapper)
در این روش، به‌جای لینک کردن کد، برنامهٔ به‌صورت یک Executable مستقل اجرا می‌شود و Go از طریق exec.Command با آن صحبت می‌کند.
این الگو برای ابزارهای سنگین، مانند پردازش تصویر و ویدئو ، بسیار پایدار و متداول است.به این روش به علت عدم وابستگی مستقیم برنامه کد خارجی و همچنین سادگی پیاده‌سازی نگاه ویژه داشته باشید
برای مثال این یک Wrapper برای FFmpeg است.
https://github.com/u2takey/ffmpeg-go



این چهار مسیر، ترجمهٔ کامل، اجرای WASM و فراخوانی FFI و Wrapper، نشان می‌دهند که رهایی از cgo در گولنگ نه‌تنها ممکن است، بلکه امروز به‌صورت کاملاً عملی در پروژه‌های واقعی استفاده می‌شود.

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

موفق باشید! 🌹

@srfirouzi_channel

دو نگاه متفاوت به Project Layout در گولنگ
(انتخاب میان سادگی گولنگ و جذابیت ستاره‌های بالا)

مدت‌هاست دو الگوی مشهور برای ساختاردهی پروژه‌های گولنگ مطرح هستند:

۱. الگوی پیشنهادی در سایت رسمی گولنگ:
https://go.dev/doc/modules/layout

۲. ریپوزیتوری پرطرفدار golang-standards/project-layout در گیت‌هاب:
https://github.com/golang-standards/project-layout

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

گولنگ بر فلسفه‌ای ساده بنا شده است؛ فلسفه‌ای که در اسناد رسمی آن کاملاً مشهود است. ساختار رسمی، ساده، شفاف و مستقیم است. اما لایوت پرستاره‌ی گیت‌هاب، با وجود اعلام صریح در README که «استاندارد رسمی نیست»، اما با انتخاب نام golang-standards برای ریپوزیتوری گیت‌هاب خود و نوع ارائه خود رگه‌هایی از پیچیدگی و استانداردسازی غیررسمی را ارایه می‌دهند. که ممکن است به کاربر مبتدی القا ‌کند که استاندارد رسمی است.

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

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

البته نمی‌شود ترند بودن یک ابزار، معماری و ... یا project layout را نادیده گرفت. توجه افراد زیاد خود، می‌تواند اعتبار بیاورد.

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

موفق باشید! 🌹

@srfirouzi_channel

سلام

نسخه بتا کتابچه راهنمای Bash که تلاش شده معایب نوشتاری آن گرفته شود.

موفق باشید! 🌹

@srfirouzi_channel

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

موفق باشید! 🌹

@srfirouzi_channel

کوروتین‌ها؛ قدرت یا دام؟
(وقتی استفاده بی‌پروا از Goroutineها منابع و کارایی را تهدید می‌کند)

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

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

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

اگر میلیون‌ها Goroutine همزمان اجرا شوند، نه تنها حافظه زیادی مصرف می‌شود، بلکه زمان CPU برای سویچ بین آنها نیز افزایش می‌یابد و برنامه کند یا ناپایدار می‌شود.

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

فراموش نکنیم که استفاده بهینه از ابزار و منابع و... به معنای کم استفاده کردن نیست به‌جا استفاده کردن است

موفق باشید! 🌹

@srfirouzi_channel

سلام

یک نکته مهم

بین توضیح دادن ساده و نوشتن کد ساده با ساده‌انگاری مسئله تفاوت فاحشی وجود دارد.

برای نوشتن کد ساده، باید مسئله را عمیقاً درک کرد:

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

این امکان ندارد مگر با تفکر سیستماتیک و عمیق نسبت به مسئله.

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

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

موفق باشید! 🌹

@srfirouzi_channel

سلام

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

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

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

موفق باشید! 🌹

@srfirouzi_channel

بدهی فنی (Technical Debt)
(هزینه‌ی تصمیم‌های سریع)

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

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

برخی از بدهی فنی رایج:

- کدی که تغییر یا توسعه آن بیش از حد دشوار شده است
- معماری‌ای که دیگر پاسخگوی نیازهای جدید نیست
- میان‌برهای موقت که در ابتدا ساده بودند اما امروز به گره‌هایی پیچیده تبدیل شده‌اند

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

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

موفق باشید! 🌹

@srfirouzi_channel

هرچند باید زبان فارسی را پاس داشت،

اما گاهی ترجمهٔ تحت‌اللفظیِ واژه‌هایی که معادل فارسی ندارند، چندان خوش‌صدا از آب درنمیاد.

مثلاً همین
آخه «بوی کد» شد معادل ؟! 😅😁

بوی کد Code Smell
(وقتی کد حرف می‌زند اما شنیده نمی‌شود)

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

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

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

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

موفق باشید! 🌹

@srfirouzi_channel

سلام

هر چند به عنوان یک توسعه‌دهنده تک نفره (Solo Developer) که برای توسعه نرم افزار در هر دو زمینه دیزاین و برنامه نویسی فعالیت دارم این تعاریف بیان شده در پست‌های قبل را تا حدی خشک و دور از واقعیت می دانم و پیشتر هم گفتم که t-shaped شاید بهترین و منطقی ترین شکل توانمندی باشه ( البته در تیم )، اول صبح تصمیم گرفتم تعاریف متداول در این دو زمینه رو لیست کنم.

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

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

بیایم در زمینه های مختلف شغلی فیلد خود و حتی فیلد و زمینه‌های دیگر اطلاع و دانش مکفی پیدا کنیم تا مفید‌تر برای خود و دیگران باشیم

موفق باشید! 🌹

@srfirouzi_channel

تفاوت «طراح رابط کاربری»، «طراح تجربه کاربری» و «پژوهشگر تجربه کاربری»

در دنیای طراحی دیجیتال، مفاهیمی مانند UI و UX اغلب در کنار هم آورده می‌شوند، اما هر کدام حوزه و مهارت خاص خود را دارند. برای ساخت یک محصول دیجیتال موفق، شناخت نقش‌های مختلف در این حوزه ضروری است.

۱. طراح رابط کاربری (UI Designer)
طراح رابط کاربری (UI Designer) مسئول ظاهر و حس بصری محصول است. او با رنگ‌ها، تایپوگرافی، چیدمان، آیکون‌ها و سبک گرافیکی کار می‌کند تا محیطی زیبا، منسجم و کاربردی بسازد. هدفش این است که کاربر هنگام استفاده از نرم‌افزار یا وب‌سایت، تجربه‌ای خوشایند و دلپذیر از نظر بصری داشته باشد.
تمرکز اصلی او روی سؤال «چگونه دیده می‌شود؟» است.

۲. طراح تجربه کاربری (UX Designer)
طراح تجربه کاربری (UX Designer) بر مسیر تعامل کاربر با محصول تمرکز دارد. او ساختار، جریان، و منطق استفاده از سیستم را طراحی می‌کند تا کاربر بتواند با کمترین سردرگمی و بیشترین رضایت به هدف خود برسد. در واقع، UX طراحی رفتار کاربر است، نه ظاهر.
تمرکز اصلی او روی سؤال «چگونه کار می‌کند؟» است.

۳. پژوهشگر تجربه کاربری (UX Researcher)
پژوهشگر تجربه کاربری (UX Researcher) به جمع‌آوری داده، تحلیل رفتار کاربران، و آزمودن فرضیه‌ها می‌پردازد. او از طریق مصاحبه، تست کاربردپذیری، و تحلیل داده‌ها تلاش می‌کند نیاز واقعی کاربران را بشناسد. خروجی کار او پایه تصمیم‌گیری UX Designer است.
تمرکز اصلی او بر سؤال «کاربر واقعاً چه می‌خواهد؟» است.

جمع‌بندی
اگر بخواهیم به‌صورت ساده بیان کنیم:

- UX Researcher: می‌فهمد کاربر چه نیاز دارد
- UX Designer: طراحی می‌کند چگونه تجربه کاربر شکل بگیرد
- UI Designer: می‌سازد آن تجربه چگونه دیده شود

در کنار هم، این سه نقش تضمین می‌کنند که محصول نه‌تنها زیبا، بلکه کارآمد و کاربردی باشد.

موفق باشید! 🌹

@srfirouzi_channel

تفاوت «توسعه‌دهنده»، «مهندس نرم‌افزار» و «دانشمند رایانه»

در دنیای فناوری اطلاعات، اصطلاحاتی مانند توسعه‌دهنده (Developer)، مهندس نرم‌افزار (Software Engineer) و دانشمند رایانه (Computer Scientist) اغلب به‌جای هم استفاده می‌شوند، اما در واقع نقش‌ها، اهداف و نوع تفکر هرکدام متفاوت است.

۱. توسعه‌دهنده (Developer)
توسعه‌دهنده کسی است که مستقیماً با کد و محصول درگیر است. تمرکز او بر ساخت، پیاده‌سازی و بهبود برنامه‌ها است. توسعه‌دهنده معمولاً با ابزارها، فریم‌ورک‌ها و زبان‌های برنامه‌نویسی کار می‌کند تا نیاز مشخصی را در قالب نرم‌افزار برطرف کند. نگاه او بیشتر عملی است تا نظری.

۲. مهندس نرم‌افزار (Software Engineer)
مهندس نرم‌افزار فراتر از نوشتن کد به طراحی سیستماتیک و ساختارمند نرم‌افزار می‌پردازد. او از اصول مهندسی مانند ماژولار بودن، مقیاس‌پذیری، پایداری و نگهدارپذیری استفاده می‌کند تا نرم‌افزار را به‌صورت اصولی و قابل توسعه بسازد. اگر توسعه‌دهنده بیشتر بر خروجی و عملکرد فوری تمرکز دارد، مهندس نرم‌افزار بر معماری و پایداری بلندمدت تأکید می‌کند.

۳. دانشمند رایانه (Computer Scientist)
دانشمند رایانه بیشتر به مفاهیم بنیادی و نظری پشت فناوری می‌پردازد. او الگوریتم‌ها، ساختار داده‌ها، نظریه محاسبه، هوش مصنوعی و معماری رایانه را مطالعه می‌کند. هدف او حل مسائل بنیادی و بهبود روش‌های محاسباتی است. دانشمند رایانه معمولاً با مفاهیم انتزاعی‌تر سروکار دارد تا با پروژه‌های عملی روزمره.

اگر بخواهیم تفاوت را خلاصه کنیم:

- دانشمند رایانه: پایه‌گذار نظریه‌ها و الگوریتم‌ها
- مهندس نرم‌افزار: طراح سیستم‌های پایدار و قابل گسترش
- توسعه‌دهنده: سازنده محصول نهایی و کاربردی

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

موفق باشید!‌ 🌹

@srfirouzi_channel