#پست_مجدد این پست تا به حال بیش از ۲۶۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

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

https://www.thoughtworks.com/insights/blog/5-tips-being-effective-tech-lead

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۳۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

یکی از تکنیک‌هایی که در مدیریت پروژه‌های نرم‌افزاری برای مدیریت کارها استفاده می‌شود استفاده از مفهوم «کانبان» است. این روش که شرکت تویوتا از آن در سیستم تولید just-in-time خود استفاده می‌کند برای پروژه‌های نرم‌افزاری نیز سازگار شده‌است.
یکی از اهداف کانبان، شناسایی گلوگاه‌های کاری است تا بتوان به فرایندی بهینه‌تر برای تولید نرم‌افزار رسید.

لینک زیر پس از توضیح مفهوم کانبان، نحوه استفاده از بورد کانبان را در پروژه‌های نرم‌افزاری شرح داده‌است.

https://kanbanblog.com/explained/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. ابزارهای آنلاین برای تست محصولات تحت وب بر روی نسخه‌های مختلف مرورگرها

https://t.iss.one/SoftwarePhilosophy/1335

۲. آشنایی با Logical Query Processing

https://t.iss.one/SoftwarePhilosophy/1337

۳. آشنایی با ابزار و کتابخانه‌های مناسب برای مصورسازی داده در صفحه وب

https://t.iss.one/SoftwarePhilosophy/1339

۴. نکاتی برای بهبود عملکرد مدیران فنی

https://t.iss.one/SoftwarePhilosophy/1341

۵. توضیحاتی در رابطه با مفهوم کانبان و نحوه استفاده از بورد کانبان

https://t.iss.one/SoftwarePhilosophy/1343

ـــــــــــ

@SoftwarePhilosophy

رویداد «استارتاپ ویکند» می‌تواند یکی از رویدادهای بسیار تاثیر گذار و مسیر ساز زندگی هر برنامه‌نویس باشد. برنامه‌نویسان معمولا در این رویدادها با بعدهای دیگر یک محصول نرم‌افزاری آشنا می‌شوند. این مفاهیم با الگوریتم و مفاهیمی که ما به عنوان برنامه‌نویس به آنها عادت کرده‌ایم فاصله بسیار زیادی دارد.
رویداد استارتاپ ویکند فرصت خیلی خوبی است که این مفاهیم را به صورت عملی و در ۳ روز به صورت فشرده تجربه کنیم.

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

ما نیز از طرف کانال‌های «فلسفه نرم‌افزار» و «فلسفه دیزاین» در نقش منتور در این رویداد در خدمت شما خواهیم بود.

البته ظاهرا ظرفیت برای ثبت‌نام برنامه‌نویسان پر شده، ولی امکان ثبت‌نام به عنوان ux هنوز وجود دارد.

منتظر شما هستیم.

همچنین برای اعضای کانال «فلسفه نرم‌افزار» یک کد تخفیف در نظر گرفته‌شده است که می‌توانید در هنگام ثبت‌نام از آن استفاده کنید.

😱 کد تخفیف مخصوص «فلسفه نرم‌افزار»: Philosophy

👀 ثبت‌نام استارتاپ ویکند: https://SWTBlockchain.com

⁉️ برای مشاهده و نوشتن نظرات خود در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/RWhq30la8Fz

#مهران_داودی (https://mehrandvd.me)


کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۲۲۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

فرایند رفع Bug و یکپارچه کردن آن با فرایند توسعه نرم‌افزار معمولا یکی از چالش‌هایی است که تیم‌های برنامه‌نویسی با آن مواجه می‌شوند. معمولا اسپرینت‌ها بر اساس نیازمندی‌ها برنامه‌ریزی می‌شوند) و باگ‌ها استثناهایی هستند که در اجرای معمولی اسپرینت اختلال ایجاد می‌کنند (در متدولوژی‌های مختلف نیازمندی به عنوان استوری یا Backlog یا Requirement شناخته می‌شود). در قبال یکپاچه کردن فرایند رفع باگ‌ها می‌توان از دو رویکرد استفاده کرد.
۱. در یک اسپرینت می‌توان با باگ‌ها همانند یک نیازمندی برخورد کرد.
۲. در اسپرینت می‌توان با باگ‌ها همانند تسک‌هایی برخورد کرد که مربوط به یک نیازمندی خاص هستند و اصولا هر باگ حتما باید به عنوان فرزند یک نیازمندی تعریف شود.

هرکدام از این روش‌ها مزایایی دارد. در لینک زیر این مفاهیم شرح داده‌شده و نمودار فرایند چرخش باگ در فرایند‌های Agile, Scrum و CMMI مقایسه شده است.

https://www.visualstudio.com/docs/work/backlogs/manage-bugs

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

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

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

https://msdn.microsoft.com/en-us/library/ee191595(v=vs.100).aspx

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۱۹۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

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

لینک زیر مفهوم Planning Poker که در اسکرام استفاده می‌شود را توضیح داده و برخی از دلایل پشت فرایند آن را هم تشریح کرده‌است.

https://en.wikipedia.org/wiki/Planning_poker

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۲۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

گرافیک سه بعدی کامپیوتری و ساخت بازی‌های کامپیوتری جز تکنولوژی‌های پیچیده محسوب می‌شود. اینکه یک ویدئو ساخته شده سه بعدی بتواند کاملا واقعی به نظر برسد کاری بسیار سخت است. در حقیقت ۳ عامل خیلی مهم وجود دارد که باعث واقعی شدن یک نمایش گرافیکی سه بعدی می‌شود.
۱. حرکت‌های طبیعی (Motion)
۲. سایه‌ها (Shadow)
۳. بافت‌ها (Texture)
مفهوم سایه فقط به سایه جسم روی زمین ختم نمی‌شود. به عنوان مثال، برای اینکه موهای یک شخص طبیعی دیده شود سایه تک تک تارهای مو باید به درستی روی بقیه تارهای مو بیفتد و این یعنی حجم وحشتناکی از محاسبات در ثانیه! مفهوم بافت مفهومی است که به یک مدل سه بعدی معنای قابل لمس می‌دهد و آن را برای ما ملموس می‌کند.

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

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

کانال تلگرام:
@SoftwarePhilosophy

___

#پست_مجدد این پست تا به حال بیش از ۲۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

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

https://www.infoworld.com/article/2905918/microsoft-net/choosing-the-right-technology-for-building-your-service-layer-in-net.html

#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

کانال تلگرام:
@SoftwarePhilosophy

___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. دو رویکرد اسپرینت در یکپاچه کردن فرایند رفع باگ‌ها

https://t.iss.one/SoftwarePhilosophy/1347

۲. در یک جلسه Sprint Planning چه می‌گذرد؟

https://t.iss.one/SoftwarePhilosophy/1349

۳. آشنایی با مفهوم Planning Poker در اسکرام

https://t.iss.one/SoftwarePhilosophy/1351

۴. گرافیک سه بعدی کامپیوتری

https://t.iss.one/SoftwarePhilosophy/1354
https://t.iss.one/SoftwarePhilosophy/1353

۵. انتخاب تکنولوژی درست برای طراحی لایه سرویس

https://t.iss.one/SoftwarePhilosophy/1356

ـــــــــــ

@SoftwarePhilosophy

چالش «کی رابطه لود شود؟» و راه‌حل‌های جالب Entity Framework Core

مفهوم Loading Related Data یکی از مفاهیم مهمی است که هنگام نوشتن برنامه‌هایی که حساسیت performance بالایی دارند بسیار مهم است. فرض کنید در برنامه لیست blogs لود شده‌است. آیا برای هر یک از blog های لود شده در آینده به blog.Posts و blog.Owner نیاز داشته باشیم، کی باید لود شوند. اینجاست که یک برنامه‌نویس خوب باید یک سیاست مناسب اتخاذ کند.

۱. سیاست (Eager Loading): همه اطلاعات همان اول لود شوند. این سیاستی است که معمولا وقتی اتخاذ می‌شود که هنگام استفاده از blogs تقریبا برای همه blog ها نیاز به اطلاعات این رابطه‌ها داریم. مثلا وقتی که قرار است همه این اطلاعات را چاپ کنیم.

۲. سیاست (Deffered Loading): هر وقت نیاز به لود کردن یک رابطه بود، همان موقع لود شود. در حقیقت، لود شدن یک رابطه تا هنگامی که واقعا به آن نیاز است به تعویق انداخته می‌شود. برای مثال فرض کنید قرار است بلاگ‌ها به کاربر نمایش داده شوند و در صورتی که کاربر روی یکی کلیک کرد، اطلاعات مربوط به owner و posts نمایش داده شود. در این حالت که کاربر شاید روی فقط چند تا blog کلیک کند، اصلا منطقی نیست که برای تمامی blog ها این اطلاعات لود شود چون شاید کاربر روی یکی کلیک کند. کافیست زمانی که کاربر یک بلاگ را انتخاب کرد، اطلاعات رابطه‌ای آن لود شود.

در ef core استراتژی‌های مختلفی برای این سناریو در نظر گرفته شده:
۱. استراتژی Eager Loading: در این استراتژی در همان اجرای اولیه navigation property های مورد نیاز توسط Include اعلام می‌شود و همه آنها همان اول لود می‌شوند. تغییر معماری جالبی که در ef core نسبت به ef داده شده معرفی مفهوم جالب ThenInclude است.

۲. استراتژی Explicit Loading: این استراتژی اولین بار در ef core 1.1 معرفی شده و برنامه‌نویس در هر جایی که نیاز داشت می‌تواند یک navigation property را لود کند.

۳. استراتژی Lazy Loading: این استراتژی در نسخه ef core 2.1 اضافه شده و با استفاده از proxy کردن هر پروپرتی را هنگام نیاز لود می‌کنم. البته تجربه نشان می‌دهد این مکانیز همیشه برنامه‌نویسان را به اشتباه می‌اندازد و پیشنهاد می‌شود از آن استفاده نشود.

لینک زیر به طور کامل و به همران مثال این ویژگی‌ها را تشریح کرده است.

https://docs.microsoft.com/en-us/ef/core/querying/related-data#including-multiple-levels

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:

https://ow.ly/ujkD30lgxfn

#مهران_داودی (https://ow.ly/GwIl309lFEm)

کانال تلگرام:
@SoftwarePhilosophy


___

#پست_مجدد این پست تا به حال بیش از ۲۳۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد

یکی از مراحل مهم در چرخه تولید نرم افزار، تست آن است که باعث بهبود نرم افزار و بالا رفتن قابلیت اطمینان آن می شود.
اهمیت این مرحله به قدری است که پیشنهاد می شود فرایند تست از همان مراحل ابتدایی چرخه تولید مشخص و اجرا شود تا نواقص و مشکلات از همان ابتدا نمایان و برای رفع آنها اقدام شود.
برای برنامه ریزی اینکه تست نرم افزار چگونه باید انجام شود تا تمام سیستم و تمام امکانات آن تست شود، test case هایی نوشته میشود که هر کدام روش تست یک قسمت خاص از سیستم را مشخص می کند. جهت تکمیل این test case ها و با توجه به توسعه روز به روز محصول و همچنین تعریف test plan ها برای تست دوره ای کامل سیستم، نیاز به مدیریت دقیق و کارآمد هست.
نرم افزار Microsoft Test Manager یکی از نرم افزارهای قدرتمند در این زمینه است که امکان ایجاد Test case و همچنین دسته بندی و مدیریت آسان test planها را فراهم می کند.
لینک زیر quick start guide برای این استفاده از این نرم افزار است.

https://msdn.microsoft.com/en-us/library/dd380763(v=vs.110).aspx

#مریم_داودی

لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a

کانال تلگرام:
@SoftwarePhilosophy

___