در این هفته قرار از دو پروژه جدید که یکی از اون ها تکمیل شده رونمایی کنیم 🔥
یکی مربوط به ترجمه کتاب هاست.😉
و دیگری هم، دوره های آموزشی رایگان دات نت.😍
یکی مربوط به ترجمه کتاب هاست.😉
و دیگری هم، دوره های آموزشی رایگان دات نت.😍
👏3❤1👍1
📘 کتاب "C# 12 in a Nutshell" – ترجمه فارسی
بعد از مدت‌ها تلاش، ترجمه کامل این کتاب ارزشمند رو آماده کردم.
این کتاب یکی از جامع‌ترین منابع یادگیری و مرجع زبان سی‌شارپ 12 هست که حالا می‌تونید نسخه فارسی اون رو رایگان از گیت‌هاب بخونید.
🔗 لینک دسترسی:
github.com/hheydarian/csharp-12-in-a-nutshell-persian
امیدوارم به درد علاقه‌مندان دات‌نت و برنامه‌نویس‌های فارسی‌زبان بخوره 💙
بعد از مدت‌ها تلاش، ترجمه کامل این کتاب ارزشمند رو آماده کردم.
این کتاب یکی از جامع‌ترین منابع یادگیری و مرجع زبان سی‌شارپ 12 هست که حالا می‌تونید نسخه فارسی اون رو رایگان از گیت‌هاب بخونید.
🔗 لینک دسترسی:
github.com/hheydarian/csharp-12-in-a-nutshell-persian
امیدوارم به درد علاقه‌مندان دات‌نت و برنامه‌نویس‌های فارسی‌زبان بخوره 💙
❤10🔥2👨💻1🆒1
«ما لازم نیست از بقیه باهوشتر باشیم.
ما باید از بقیه منظم‌تر باشیم.»
— وارن بافت
این اصل، هم در سرمایه‌گذاری و هم در فلسفه رواقی‌گری بنیادین است.
موضوع نبوغ نیست؛ موضوع رفتار است.
چگونه میتوان هر روز انضباط رواقی را تمرین کرد:
🧘♂️ واکنش هایت را کنترل کن
همه‌چیز ارزش پاسخ دادن ندارد.
📆 ثبات بساز
روالهای منظم مهم‌تر از تلاشهای پراکنده‌اند.
📵 از حواس‌پرتی دوری کن
از زمانت مثل ارزشمندترین داراییات محافظت کن — چون همین است.
🧭 به هدفت پایبند بمان
دنبال نکن — انتخاب کن.
🛠 کار را انجام بده، حتی وقتی خسته‌کننده است
بیشتر مردم در این نقطه متوقف میشوند. این همان برتری توست.
ذهن، مانند یک عضله، با تکرار قویتر میشود.
و انضباط همان تمرین روزانه است.
(با سپاس از @Lara R در پینترست)
ما باید از بقیه منظم‌تر باشیم.»
— وارن بافت
این اصل، هم در سرمایه‌گذاری و هم در فلسفه رواقی‌گری بنیادین است.
موضوع نبوغ نیست؛ موضوع رفتار است.
چگونه میتوان هر روز انضباط رواقی را تمرین کرد:
🧘♂️ واکنش هایت را کنترل کن
همه‌چیز ارزش پاسخ دادن ندارد.
📆 ثبات بساز
روالهای منظم مهم‌تر از تلاشهای پراکنده‌اند.
📵 از حواس‌پرتی دوری کن
از زمانت مثل ارزشمندترین داراییات محافظت کن — چون همین است.
🧭 به هدفت پایبند بمان
دنبال نکن — انتخاب کن.
🛠 کار را انجام بده، حتی وقتی خسته‌کننده است
بیشتر مردم در این نقطه متوقف میشوند. این همان برتری توست.
ذهن، مانند یک عضله، با تکرار قویتر میشود.
و انضباط همان تمرین روزانه است.
(با سپاس از @Lara R در پینترست)
👍2
۵۰ کانال یوتیوب آموزش برنامه نویسی
🟢 Python
1. Core Schafer
2. Sentdex
3. Tech with Time
4. Code with Harry
5. Real Python
🟠 Java
1. Alex Lee
2. Programming with Mosh
3. Java Brains
4. Coding with John
⚪ ML
1. Krish Naik
2. Stat Quest with Josh Starmer
3. Data School
4. Connor Shorten
🔵 Go
1. Just For Func
2. Matt Kodyb
3. Nic Jackson
⚪ Rust
1. Let's Get Rusty
2. Chris Biscardi
🟡 JavaScript
1. Traversy Media
2. JavaScript Mastery
3. Code Volution
4. Web Dev Simplified
5. Fun Fun Function
🟣 C#
1. I Am Tim Corey
2. Nick Chapsas
3. tutorials EU
🟠 Swift / IOS
1. Sean Allen
2. Kodeco
🔵 Flutter / Dart
1. Flutter
2. Reso Coder
🟤 PHP
1. Traversy Media
🟠 Ruby
1. GoRails
🔵 SQL & Database
1. Net Ninja
2. Caleb Curry
🔴 Web Frameworks
1. Acadmind
2. Net Ninja
3. Fireship
⚪ DevOps & Cloud
1. Tech World with Nana
2. A Cloud Guru
🔵 C / C ++
1. Caleb Curry
2. The Cherno
🔴 Kotlin
1. Philipp Lackner
2. Kotlin by JetBrains
❤3👍2
یادآوری کوتاه به شرکت‌هایی که بر اساس سبز بودن نمودار مشارکت GitHub استخدام می‌کنند:
- همه‌ی توسعه‌دهندگان در پروژه‌های متن‌باز مشارکت نمی‌کنند.
- همه‌ی توسعه‌دهندگان آخر هفته‌هایشان را صرف پوش کردن کد در GitHub نمی‌کنند.
- همه‌ی توسعه‌دهندگان بعد از کار، ساعت‌ها وقت برای ساخت پروژه‌های جانبی ندارند.
- همه‌ی توسعه‌دهندگان نمی‌توانند یا نمی‌خواهند بیرون از شغلشان کدنویسی کنند.
- همه‌ی توسعه‌دهندگان باور ندارند که «خانه‌های سبز بیشتر» به معنای استعداد بیشتر است.
و واقعاً هم اشکالی ندارد.
چون کدنویسی در محیط کار خودش درس‌های زیادی دارد:
1. نتایجی که ارائه می‌دهی، مسیر رشد، نفوذ و اعتمادی را شکل می‌دهد که نزد تیم، ذی‌نفعان و مشتریان می‌سازی.
2. بازخورد سریع می‌گیری. همکارانت در موفقیت تو سرمایه‌گذاری کرده‌اند و مسائلی که حل می‌کنی اهمیت واقعی دارند—روی مشتریان اثر می‌گذارند، نه فقط روی تئوری.
پروژه‌های جانبی می‌توانند فوق‌العاده باشند برای کشف فناوری‌های جدید یا ارضای خلاقیت.
اما نگذار کسی قانعت کند که آن‌ها برای اثبات ارزش تو به‌عنوان توسعه‌دهنده ضروری‌اند.
ارزش تو به‌عنوان توسعه‌دهنده در تفاوتی است که در کار ایجاد می‌کنی، مسائلی که حل می‌کنی و اثری که بر جای می‌گذاری.
مسیر شغلی تو با رنگ نمودار GitHub تعریف نمی‌شود.
بلکه با اثری تعریف میشود که در جایی که واقعاً اهمیت دارد خلق می‌کنی.
🔗 LinkedIn Post
- همه‌ی توسعه‌دهندگان در پروژه‌های متن‌باز مشارکت نمی‌کنند.
- همه‌ی توسعه‌دهندگان آخر هفته‌هایشان را صرف پوش کردن کد در GitHub نمی‌کنند.
- همه‌ی توسعه‌دهندگان بعد از کار، ساعت‌ها وقت برای ساخت پروژه‌های جانبی ندارند.
- همه‌ی توسعه‌دهندگان نمی‌توانند یا نمی‌خواهند بیرون از شغلشان کدنویسی کنند.
- همه‌ی توسعه‌دهندگان باور ندارند که «خانه‌های سبز بیشتر» به معنای استعداد بیشتر است.
و واقعاً هم اشکالی ندارد.
من از وقتی کارم را شروع کردم، بیرون از شغل روزانه‌ام خیلی کد ننوشته‌ام.
اما این هیچ‌وقت مانع رشد، یادگیری یا حل مسائل سخت دنیای واقعی نشد.
چون کدنویسی در محیط کار خودش درس‌های زیادی دارد:
1. نتایجی که ارائه می‌دهی، مسیر رشد، نفوذ و اعتمادی را شکل می‌دهد که نزد تیم، ذی‌نفعان و مشتریان می‌سازی.
2. بازخورد سریع می‌گیری. همکارانت در موفقیت تو سرمایه‌گذاری کرده‌اند و مسائلی که حل می‌کنی اهمیت واقعی دارند—روی مشتریان اثر می‌گذارند، نه فقط روی تئوری.
پروژه‌های جانبی می‌توانند فوق‌العاده باشند برای کشف فناوری‌های جدید یا ارضای خلاقیت.
اما نگذار کسی قانعت کند که آن‌ها برای اثبات ارزش تو به‌عنوان توسعه‌دهنده ضروری‌اند.
ارزش تو به‌عنوان توسعه‌دهنده در تفاوتی است که در کار ایجاد می‌کنی، مسائلی که حل می‌کنی و اثری که بر جای می‌گذاری.
مسیر شغلی تو با رنگ نمودار GitHub تعریف نمی‌شود.
بلکه با اثری تعریف میشود که در جایی که واقعاً اهمیت دارد خلق می‌کنی.
🔗 LinkedIn Post
❤6👍2🆒1
چرا مفاهیم پایه مهم‌اند
احتمالاً خیلی‌هامان این حس را تجربه کرده‌ایم؛ وقتی وارد دنیای معماری و تکنولوژی‌های جدید می‌شویم، حجم مطالب آن‌قدر زیاد است که گیج می‌شویم. هر منبعی را که باز می‌کنیم پر از الگوهای طراحی و فریم‌ورک‌های پیچیده است.
بسیاری از ما یک‌بار این اشتباه را کرده‌ایم؛ مستقیم سراغ Clean Architecture و DDD رفتیم، بدون آن‌که ابتدا پایه‌ها را درست بلد باشیم. در یک پروژه‌ی ASP .NET Core، تنها به خاطر ندانستن درست async/await یا Dependency Injection، ساعت‌ها زمان از دست رفته است. در ظاهر مشکل از معماری به نظر می‌رسد، اما ریشه‌ی اصلی در ضعف مفاهیم پایه بوده است.
چرا این اتفاق رخ می‌دهد؟
وقتی زبان C# را خوب بلد نباشیم، هر خطا می‌تواند ما را متوقف کند.
وقتی اصول شی‌گرایی یا SOLID را درک نکرده باشیم، پروژه‌ای که کمی بزرگ میشود به‌سرعت به کدهای به‌هم‌ریخته تبدیل میشود.
وقتی ساختار اصلی .NET را نشناسیم، معماری‌های پیشرفته بیشتر شبیه معما به نظر می‌رسند تا راه‌حل.
راه‌حل
راه‌حل ساده ولی حیاتی این است که یک قدم به عقب برگردیم و روی پایه‌ها تمرکز کنیم. حوزه‌هایی مانند:
- ویژگی‌های C# مثل generics، delegates، LINQ، async/await
- اصول شی‌گرایی و SOLID
- مبانی .NET Core مثل middleware و DI
- ساختمان داده‌ها و الگوریتم‌ها
- مدیریت خطا و دیباگ
نتیجه
وقتی مفاهیم پایه تقویت شوند، معماری‌های مدرن هم معنای واقعی خود را پیدا می‌کنند. جداسازی لایه‌ها در Clean Architecture دیگر یک شعار نیست، بلکه نیاز طبیعی کد است. مدل دامنه در DDD دیگر پیچیده به نظر نمی‌رسد، چون می‌دانیم بر چه اساسی ارزشمند است.
ابزارها و تکنولوژی‌ها هر روز تغییر می‌کنند، اما مفاهیم پایه‌ای همیشه ثابت باقی می‌مانند. اگر در میان پیچیدگی‌های امروز احساس سردرگمی داشته‌ایم، پاسخ اغلب در همان اصول ساده و بنیادی نهفته است.
🔗 LinkedIn Post
احتمالاً خیلی‌هامان این حس را تجربه کرده‌ایم؛ وقتی وارد دنیای معماری و تکنولوژی‌های جدید می‌شویم، حجم مطالب آن‌قدر زیاد است که گیج می‌شویم. هر منبعی را که باز می‌کنیم پر از الگوهای طراحی و فریم‌ورک‌های پیچیده است.
بسیاری از ما یک‌بار این اشتباه را کرده‌ایم؛ مستقیم سراغ Clean Architecture و DDD رفتیم، بدون آن‌که ابتدا پایه‌ها را درست بلد باشیم. در یک پروژه‌ی ASP .NET Core، تنها به خاطر ندانستن درست async/await یا Dependency Injection، ساعت‌ها زمان از دست رفته است. در ظاهر مشکل از معماری به نظر می‌رسد، اما ریشه‌ی اصلی در ضعف مفاهیم پایه بوده است.
چرا این اتفاق رخ می‌دهد؟
وقتی زبان C# را خوب بلد نباشیم، هر خطا می‌تواند ما را متوقف کند.
وقتی اصول شی‌گرایی یا SOLID را درک نکرده باشیم، پروژه‌ای که کمی بزرگ میشود به‌سرعت به کدهای به‌هم‌ریخته تبدیل میشود.
وقتی ساختار اصلی .NET را نشناسیم، معماری‌های پیشرفته بیشتر شبیه معما به نظر می‌رسند تا راه‌حل.
راه‌حل
راه‌حل ساده ولی حیاتی این است که یک قدم به عقب برگردیم و روی پایه‌ها تمرکز کنیم. حوزه‌هایی مانند:
- ویژگی‌های C# مثل generics، delegates، LINQ، async/await
- اصول شی‌گرایی و SOLID
- مبانی .NET Core مثل middleware و DI
- ساختمان داده‌ها و الگوریتم‌ها
- مدیریت خطا و دیباگ
نتیجه
وقتی مفاهیم پایه تقویت شوند، معماری‌های مدرن هم معنای واقعی خود را پیدا می‌کنند. جداسازی لایه‌ها در Clean Architecture دیگر یک شعار نیست، بلکه نیاز طبیعی کد است. مدل دامنه در DDD دیگر پیچیده به نظر نمی‌رسد، چون می‌دانیم بر چه اساسی ارزشمند است.
ابزارها و تکنولوژی‌ها هر روز تغییر می‌کنند، اما مفاهیم پایه‌ای همیشه ثابت باقی می‌مانند. اگر در میان پیچیدگی‌های امروز احساس سردرگمی داشته‌ایم، پاسخ اغلب در همان اصول ساده و بنیادی نهفته است.
🔗 LinkedIn Post
👍7❤2
تفاوت کسب‌وکار (𝐁𝐮𝐬𝐢𝐧𝐞𝐬𝐬) و محصول (𝐏𝐫𝐨𝐝𝐮𝐜𝐭)
«بارها در سازمان‌های مختلف دیده‌ام که کسب‌وکار (Business) و محصول (Product) با هم اشتباه گرفته می‌شن.
این اشتباه ساده می‌تونه منجر به شکست پروژه‌های بزرگ بشه.
🔹 کسب‌وکار (Business) یعنی:
- ما برای چه کسی کار می‌کنیم؟ (مشتری)
- چه مشکلی رو حل می‌کنیم؟ (ارزش پیشنهادی)
- چطور پول درمی‌آوریم؟ (مدل درآمدی)
- فرآیندها و عملیات کلان سازمان
🔹 محصول (Product) یعنی:
- ابزاری برای تحقق بخشی از ارزش پیشنهادی
- ویژگی‌ها و تجربه کاربری
- چرخه توسعه و بهبود مستمر
- بخشی از استراتژی کسب‌وکار، نه همه آن
❌ وقتی سازمان‌ها این دو مفهوم رو قاطی می‌کنن:
- تیم‌ها محصول رو صرفاً به‌عنوان «کسب‌وکار» می‌بینن → در نتیجه نوآوری متوقف می‌شه.
- مدیریت، محصول رو فقط یک فیچر تکنولوژیک می‌دونه → ارزش واقعی به مشتری منتقل نمی‌شه.
✅ تجربه من نشون داده که موفق‌ترین سازمان‌ها این دو مفهوم رو درست می‌فهمن:
- Business رو مثل نقشه راه می‌بینن.
- Product رو مثل وسیله‌ای برای رسیدن به مقصد.
📌 پس:
- کسب‌وکار = «چرا و چگونه ارزش ایجاد می‌کنیم»
- محصول = «چه ابزاری می‌سازیم تا اون ارزش منتقل بشه»
🔗 LinkedIn Post
«بارها در سازمان‌های مختلف دیده‌ام که کسب‌وکار (Business) و محصول (Product) با هم اشتباه گرفته می‌شن.
این اشتباه ساده می‌تونه منجر به شکست پروژه‌های بزرگ بشه.
🔹 کسب‌وکار (Business) یعنی:
- ما برای چه کسی کار می‌کنیم؟ (مشتری)
- چه مشکلی رو حل می‌کنیم؟ (ارزش پیشنهادی)
- چطور پول درمی‌آوریم؟ (مدل درآمدی)
- فرآیندها و عملیات کلان سازمان
🔹 محصول (Product) یعنی:
- ابزاری برای تحقق بخشی از ارزش پیشنهادی
- ویژگی‌ها و تجربه کاربری
- چرخه توسعه و بهبود مستمر
- بخشی از استراتژی کسب‌وکار، نه همه آن
❌ وقتی سازمان‌ها این دو مفهوم رو قاطی می‌کنن:
- تیم‌ها محصول رو صرفاً به‌عنوان «کسب‌وکار» می‌بینن → در نتیجه نوآوری متوقف می‌شه.
- مدیریت، محصول رو فقط یک فیچر تکنولوژیک می‌دونه → ارزش واقعی به مشتری منتقل نمی‌شه.
✅ تجربه من نشون داده که موفق‌ترین سازمان‌ها این دو مفهوم رو درست می‌فهمن:
- Business رو مثل نقشه راه می‌بینن.
- Product رو مثل وسیله‌ای برای رسیدن به مقصد.
📌 پس:
- کسب‌وکار = «چرا و چگونه ارزش ایجاد می‌کنیم»
- محصول = «چه ابزاری می‌سازیم تا اون ارزش منتقل بشه»
🔗 LinkedIn Post
👍3❤1
👍2🔥1👏1