🔴 برزخ مدیریت در ایران

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

مدیریت در برزخ

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

اما وقتی اوضاع خوب است، ابتدای پروژه است، افراد با هم خوب رفتار می کنند، کارها خوب جلو میرود، ما میتوانیم رهبران خوبی باشیم. همه را در تصمیم گیری دخالت می دهیم، با اعضای تیم احساس راحتی می کنیم، نگران اعضای تیم هستیم و … . در اینستاگرام عکس میگذاریم، این تیم عالی ترین تیم دنیاست، از ما بهتر وجود ندارد…

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

برزخ کجاست؟

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

تغییر از رئیس بودن به رهبری، یک پارادایم شیفت است

این را باید قبول کنیم که سالها، رئیس بودن در کارخانه ها و ساختمان سازی ها و … جواب داده است، صدها سال است که ما به این شیوه، سرکارگر با دیگران برخورد کردیم، ما سرکارگر بودیم و دیگران کارگر، آنها به رفتار زیردست بودن(وقتی رئیس نیست کار نمی کنیم) عادت کردن و ما هم به رئیس بودن. تغییر از پارادایم به یک پارادایم دیگر بسیار کار سختی است.

چرا سرعت این تغییر کند است؟

در چند شرکت اخیری که بودم، معمولا افراد باتجربه در یک رشته خاص مدیر همان بخش یا پروژه می شوند، مثلا یک برنامه نویس خوب تبدیل به مدیرپروژه می شود، یک فروشنده خوب تبدیل به مدیرفروش می شود و … .

اما مثل برنامه نویسی، فروش، بازاریابی، آیا مدیریت نیاز به تخصص یا تجربه ندارد؟ دوستان در تخصص های دیگر، زمانی برای یادگیری یا تجربه مدیریت نمی کنند. مثلا یک برنامه نویس بعد 5 سال برنامه نویسی، خواندن مقالات متعدد، نوشتن برنامه های مختلف و … بعنوان یک برنامه نویس خوب شناخته می شود، اما وقتی او مدیر می شود چنین خط سیری وجود ندارد.

برای مثال، برنامه نویسی بعنوان مدیرپروژه یا مدیرتیم، به همان میزان که زمان برای خواندن مقالات تخصصی در حوزه برنامه نویسی می کند، به همان میزان زمان برای ایجاد تیم یا انگیزش نفرات سپری نمی کند؟!

یکی از مشکلات مهم این است که صرفا افراد از داشتن عنوان “مدیر” لذت می برند، ولی اینکه این مدیر چه تخصص هایی باید داشته باشد، بعنوان یک مدیر چه مسیر رشدی باید طی کند، چه مهارت هایی باید در خود تقویت کند؟

راه عبور از این برزخ چیست؟

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

https://goo.gl/jr78bn

@iranagile

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

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

مقاله زیر ۱۰ نکته‌ مهمی که برنامه نویسان باید در مورد این فایل بدانند را شرح داده‌است.

https://weblogs.asp.net/jongalloway/10-things-asp-net-developers-should-know-about-web-config-inheritance-and-overrides

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

https://ow.ly/Ojts30aISN8

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

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


___

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

یک کد خوب نیاز به مستندسازی قوی دارد. در C#، برای این کار میتوانید از XML Documentation استفاده کنید که با سه اسلش ///، درست قبل از بلاک کد مربوطه شروع می شود.
شما می توانید خودتان نیز تگ های مورد نیاز خود را ایجاد کنید یا از لیست تگهای پیشنهادی موجود استفاده کنید.
پرکاربردترین تگ های پیشنهادی شامل موارد زیر است:
/// <summary>
/// Class or Method or Property or… summary documentation goes
///here.</summary>

/// <remarks>
/// Longer comments can be associated with a type or member through
/// the remarks tag.</remarks>


/// <value>
/// A value tag is used to describe the property value.</value>


/// <param name="s"> Parameter description for s goes here.</param>


/// <seealso cref="System.String">
/// You can use the cref attribute on any tag to reference a type or member
/// and the compiler will check that the reference exists. </seealso>


/// <returns>
/// Return results are described through the returns tag.</returns>


زمانی که با آپشن /doc کامپایل کنید، کامپایلر از روی تمام تگ‌های xml موجود در کد فایل داکیومنت XML را می سازد.
لینک زیر شرح کاملی از xml documentation و نحوه استفاده آن ارایه می دهد.

https://msdn.microsoft.com/en-us/library/z04awywx.aspx

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

https://ow.ly/Pzau30aN6fd

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

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

___

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

۱. مفهوم Regex در زبان‌های برنامه‌نویسی

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

۲. نحوه برخورد با NullReferenceException در Visual Studio 2017
#visualstudio
https://t.iss.one/SoftwarePhilosophy/848

۳. کتاب‌هایی که دیدِ من را برای همیشه تغییر داد (دیزاین)
(از زبان Julie Zhuo، معاون دیزاین فیسبوک)
https://t.iss.one/SoftwarePhilosophy/849

۴. برزخ مدیریت در ایران (Iran Agile)

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

۵. ده نکته مهم در رابطه با فایل web.config
#aspnet
https://t.iss.one/SoftwarePhilosophy/852

۶. نحوه استفاده از XML Documentation برای مستندسازی در C#
#csharp #documentation
https://t.iss.one/SoftwarePhilosophy/854

ـــــــــــ

@SoftwarePhilosophy

مفهوم Stream API در Java در بسیاری از موارد جایگزین مناسب‌تری برای حلقه‌ها است. استفاده از stream کمک می‌کند تا به طور کامل از معماری multi-core استفاده شود. همچنین این نحوه برنامه‌نویسی باعث می‌شود قطعات کد بیشتر declarative شوند. از طرفی استفاده از stream ها معایبی هم دارد. در برخی مواقع فهمیدن این کدها و در اکثر مواقع دیباگ کردن آنها سخت است.
ابزار Java Stream Debugger نام پلاگین جدید JetBrains است که به وسلیه آن می‌توان کدهای روی stream را که معمولا به صورت chain استفاده می‌شوند را به راحتی بررسی و دیباگ کرد.

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

https://plugins.jetbrains.com/plugin/9696-java-stream-debugger

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

https://ow.ly/X3T030de1Dk


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

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


___

🔴 واقعیت DevOps چیست؟

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

اما کج فهمی های زیاد در مورد DevOps وجود دارد، واقعا DevOps چیست؟

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

برای همین مابین این دو تیم یک دیوار نامرئی (و گاها در تجربه ما در ایران دیوارهای مرئی) به وجود می آمد. مفهوم دیوآپس بدنبال این است که با از بین بردن دیوار مابین (مرئی یا نامرئی) تیم ها، و افزایش تعامل نفرات، موجب افزایش سرعت تحویل ارزش به مشتری شود. پس خیلی ساده، دیوآپس فرآیندی است برای تحویل سریع ارزش به مشتری و از بین بردن هر نوع مشکل که باعث کندی در فرآیند تحویل ارزش شود.

https://goo.gl/iL3k3N

@iranagile

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

نسخه جدید کتابخانه Json.NET منتشر شد. مهمترین ویژگی جدید نسخه Json.NET 10.0 پشتیبانی آن از عملیات async است. این امکان کمک می‌کند هنگام تبدیل فایل‌های بزرگ Json، پروسس نخ به خاطر I/O بلاک نمی‌شود. به این صورت برنامه‌های Client بسیار Responsive تر می‌شوند و Web Application ها نیز بسیار scalable تر می‌شوند.

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

https://james.newtonking.com/archive/2017/03/21/json-net-10-0-release-1-async-performance-documentation-and-more

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

https://ow.ly/WUU030aPV1A

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

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


___

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

www.modotech.ir

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

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

___

🔴 مهاجرت از پروژه به محصول

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

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

در این مورد بیشتر بخوانید:

https://goo.gl/es4sYM ▶

@iranagile

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

۱. مفهوم Stream API در Java
#java #stream
https://t.iss.one/SoftwarePhilosophy/856

۲. واقعیت DevOps چیست؟ (Iran Agile)
#devops
https://t.iss.one/SoftwarePhilosophy/857

۳. آشنایی با نحوه استفاده از ویژگی async در نسخه جدید کتابخانه Json.NET
#dotnet #json #async
https://t.iss.one/SoftwarePhilosophy/859

۴. استارتاپ ویکند مدوتک ۲
#startupweekend
https://t.iss.one/SoftwarePhilosophy/860
https://t.iss.one/SoftwarePhilosophy/861

۵. مهاجرت از پروژه به محصول (Iran Agile)
#product #project
https://t.iss.one/SoftwarePhilosophy/862

ـــــــــــ

@SoftwarePhilosophy

ذخیره لاگ به صورت ساخت یافته یکی از چالش‌های مهم نرم‌فزارهای نسل جدید است. با استفاده از Serilog می‌توان Log های هر نرم‌افزار را بصورت ساخت یافته ذخیره نمود و در Log ها بصورت ساخت یافته جستجو نمود. از ویژگی‌های خوب این کتابخانه امکان ذخیره Log ها در ElasticSearch می‌باشد که با ابزار Kibana می‌توان در Log ها جستجو و آنالیز انجام داد.
در لینک زیر نحوه ذخیره لاگ‌ها از طریق Serilog در ElasticSearch و نحوه مشاهده آن در Kibana توضیح داده شده است.

https://mikelindegarde.com/post/2016/11/23/using-serilog-elasticsearch-and-kibana-for-effective-error-logging

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

https://ow.ly/1IZF30dsVoV

#علیرضا_وفی (https://ow.ly/Vna930dsUGr)


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


___

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

استفاده از هوش مصنوعی اخیرا جاذبه زیادی را در نرم‌افزارها ایجاد کرده‌است. یکی از ابزارهایی که می‌توانید در برنامه‌نویسی برنامه‌های خود از آن استفاده کنید Microsoft Cognitive Services (که قبلا به اسم پروژه آکسفورد معروف بود) است. شما با استفاده از این API می‌توانید احساساتی که در یک عکس وجود دارد را تشخصی دهید. برای مثال در لینک زیر با استفاده از این سرویس یک برنامه موبایل نوشته شده است که می‌تواند میزان رضایت کاربر از برنامه شما را از طریق عکس او تخشیص دهد.

نحوه نوشتن این برنامه برای سه پلتفرم Android, iOS, Windows 10 در لینک توضیح داده شده‌است.

https://github.com/Microsoft/XamarinAzure_ShoppingDemoApp/wiki/Cognitive-Services

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

https://ow.ly/ziQd30aSGEe

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

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


___

🔴 چگونه با افراد و ذی‌نفعان دشوار برخورد کنیم؟

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

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

https://goo.gl/Ja5riQ

@iranagile

نامگذاری به روش کباب! برای نحوه نامگذاری روش‌های مختلفی وجود دارد که هر زبان قانون خود را دارد. برای مثال حتما تا به حال از روش‌های نامگذاری PascalCase, camleCase, snake_case استفاده کرده‌اید. اخیرا یک روش نامگذاری را با اسم «روش کباب» دیدم که خیلی جالب بود! مدل kebab-case مدلی است که چون ظاهر آن شبیه این است که یک سیخ کباب از آن رد شده به kebab-case معروف شده‌است! جای خوشحالی دارد که یکی از عبارات فرهنگ ایرانی وارد اصطلاحات دنیای برنامه‌نویسی شده!

کتابخانه Lodash متدی برای تبدیل string به حالت kebab-case دارد. برای این منظور می‌توانید از _.kebabCase('my food bar') استفاده کنید که خروجی آن my-food-bar خواهد بود.

https://lodash.com/docs#kebabCase

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

https://ow.ly/Nu1030dx8j8


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

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


___

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

آیا مهاجرت به ASP.NET Core لازم است؟ نه لزوما! این جواب اولیه‌ای است که معمار ارشد مایکروسافت Dino Esposito به این سوال داده‌است. جمله جالب دیگر او این است که «کافیست که شما بدانید چطور یک نرم‌افزار وب بنویسید، و همین بس است». او در ادامه یک جمله از یک رمان را نقل قول کرده: «اگر ما بخواهیم چیزها همانطور که هستند بمانند، آنها مجبور به تغییر خواهد شد!»
بنابرین او اعتقاد دارد نسل آینده نرم‌افزارها به این سمت می‌رود و اگر می‌خواهید در آینده هنوز نرم‌افزار تحت وب بنویسید، بالاخره روزی خواهد رسید که باید ابزارهای قدیمی خود را کنار بگذارید و به سمت جلو حرکت کنید.

در پست زیر Dino نظر خود در باره فلسفه مهاجرت به ASP.NET Core را توضیح می‌دهد. نحوه نگارش او طوری است که خواندن آن بسیار آموزنده است.

https://www.linkedin.com/pulse/me-aspnet-core-you-dino-esposito

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

https://ow.ly/8Aqo30aTBEs


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

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


___