سازماندهی ساختار محصول در شرکت‌ها

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

شکستن تیم:
⁦✂️⁩ بر اساس محصول یا یک‌ ناحیه محصول، به عنوان مثال محصولات آفیس، محصول اکسل و پاورپوینت
✂️ براساس⁩ گروه مشتری/کاربر، به عنوان مثال، بانکداری شخصی برای مشتریان حقیقی، محصول بانکداری شرکتی برای مشتریان حقوقی
⁦✂️⁩ براساس دستیابی به هدف کلی، به عنوان مثال تیم متمرکز بر رشد در مقابل تیم متمرکز بر وفادارسازی کاربر
✂️⁩ ساختار موقت بر اساس ابتکارات استراتژیک شامل تیم های مختلف، به عنوان مثال، فعالیت چند ماهه برای بهبود پروسه آنبورد کردن مشتریان

مقاله کامل
https://medium.com/@jefago/establishing-a-product-organization-structure-5cb4fbc2153

@iranagile

✅ آموزش معماری تمیز (Clean Architecture) + سورس کد بهترین پیاده سازی ها

اکثر مقالاتی که این معماری رو به صورت کلی و انتزاعی توضیح دادند ممکنه برنامه نویس رو به خوبی شیرفهم نکنه مخصوصا وقتی با مفاهیمی آشنا میشن که شاید تا قبل نمیشناختین یا معادلی براش توی ذهنتون ندارین مثل Interactor و Interface Adapters و Drivers!
این موضوع حتی برای منبع اصلی Clean Artchiture یعنی مقاله شخص Robert C Martin (معروف به Uncle Bob) هم صدق میکنه هرچند که خیلی جامع و کامل توضیح داده ولی برای یه برنامه نویس سی شارپی ممکنه مبهم به نظر بیاد، مادامی که پیاده سازی عملی ازش رو نبینه.
همچنین خیلی از مقاله ها با دخیل کردن بیش از حد مورادی چون DDD و CQRS و ...، فهم اصل موضوع Clean Architecture رو برای مخاطب سخت میکنن.

🔸مقاله زیر خیلی ساده و روان و البته مختصر و مفید به توضیح معماری تمیز پرداخته و در آخر هم رفرنس های خوبی رو معرفی میکنه که پیشنهاد میکنم حتما ببینیدشون
https://www.dandoescode.com/blog/clean-architecture-an-introduction/

🔹و اما بریم سر اصل مطلب یعنی پیاده سازی؛ پیاده سازی های مختلفی از این معماری وجود داره توی اینترنت و گیتهاب که هرکس معمولا بنا به فهم و سلیقه خودش اومده یه پروژه ای ساخته که بعضا اشتباه هم هستند و صرفا اسم Clean Architecture رو به دوش میکشند

1️⃣ بهترین پیاده سازی هایی که من دیدم به ترتیب اینا هستند
https://github.com/jasontaylordev/CleanArchitecture
🔰آموزش ویدئویی این مورد توی یوتیوب هم هست که برای درک بهتر خیلی بهتون کمک میکنه
https://www.youtube.com/watch?v=5OtUm1BLmG0
https://jasontaylor.dev/clean-architecture-getting-started/

2️⃣ پیاده سازی بعدی توسط ardalis تهیه شده و ویدئو اش هم توی یوتیوب قرار داده شده
https://github.com/ardalis/CleanArchitecture

3️⃣ پیاده سازی بعدی هم خوبه و توضیحات بیشترش توی wiki خود ریپازیتوری و پست های وبلاگ نویسنده (1 و 2 و 3) + پلی لیست ویدئو هاش تو یوتیوب خود نویسنده قرار داده شده
https://github.com/ivanpaulovich/clean-architecture-manga


4️⃣ و در اخر پیاده سازی زیر که به همراه پست بلاگ نویسنده قرار داده شده
https://github.com/mmacneil/CleanAspNetCoreWebApi
________________
@DotNetZoom

به رنگ سادگی

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

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

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

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

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

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

۳- محدودیت انتخاب‌ها: انسان‌ها تمایل دارند چیزهایی را ببینند و با آن‌ها درگیر شوند که در راستای هدفشان باشد و موجب انحراف از این هدف نشود. بنابراین محدود کردن انتخاب‌ها و امکانات در راستای رسیدن کاربر به هدف مدنظرش تاثیر به‌سزایی در سادگی محصول خواهد داشت.

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

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

http://bit.ly/dxgn585

(زمان حدودی مطالعه: ۱۰ دقیقه)

نویسنده: محمدرضا پناهی

#دیزاین #سادگی

@Dexign فلسفه دیزاین


_____

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

1- آنها عوامل بیرونی را مقصر مشکلات خود می دانند.

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

2- بعنوان مربی جایی در تقویم آنها ندارید

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

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

3- آنها بیش از حد روی نکات کنکوری و تاکتیکها تمرکز می کنند.

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

وقتی مربی آنها سؤالاتی را می پرسد که نیاز به تأمل در خود دارند، اینگونه مدیران سریع ناامید می شود. آنها جواب می خواهند، نه سؤال. آنها در پاسخ به سؤالات مربی می گویند: "شما خبره هستید، شما باید به من بگویید" همه چیز به تاکتیک و سطحی بودن بر می‌گردد. (یک نشانه هشدار مربوط به این است که اگر یک رهبر بپرسد که میشه این جلسات را کوتاه تر یا فشرده تر باشند؟ 😉 )

4- آنها برای شروع "تحقیق بیشتر" یا "پیدا کردن شخص مناسب" با مربی تأخیر می کنند.

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

لینک کامل نوشته
https://hbr.org/2018/07/4-signs-an-executive-isnt-ready-for-coaching

@iranagile

✅ استفاده از قابلیت CI/CD گیتهاب به نام Github Actions
برای Build و توزیع خودکار پروژه های NET Core.

🔸سایت گیتهاب بخشی به نام GitHub Actions دارد که امکانات CI/CD را به صورت رایگان برای شما فراهم میکند. توسط این بخش می توانید پروژه خود را (مثلا بعد از هر Push یا Pull Request) به صورت خودکار Build کرده، Test های آن را اجرا کنید و از آن Publish بگیرید (البته امکانات بسیار زیادی دارد و این فقط یک مثال بود)
https://www.dotnettips.info/post/3103
🔻یادتون باشه حتما نظرات پایین صفحه رو هم بخونین که نکات مهمی توش هست

🔹مثلا کتابخانه EasyCompressor علاوه بر Build و Test خودکار، Nuget Package های خود را به ازای هر Commit ایی که Tag عددی با فرمت مشخص (مثلا 1.2.1) به سایت nuget.org آپلود میکند
https://github.com/mjebrahimi/EasyCompressor
🔻 فایل yaml. آن را میتوانید در این مسیر مشاهده کنید
________________
@DotNetZoom

حس تجربه کاربری

خیلی اوقات پیش می‌آید که دوستی گروه چت دوستان را ترک می‌کند. هیچکس نمی‌داند چرا این اتفاق افتاده‌است.

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

خودمان را جای آن شخصی بگذاریم که می‌خواهد برود.

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

آیا می‌توان این حس را بیشتر وارد دنیای دیزاین کرد؟ شاید می‌شود کاربر را موجودی «همیشه در حال ترک سرویس» در نظر گرفت و تلاش‌های خود را برای همیشه ماندن او بیشتر کرد.
چون ما انسان‌ها - متاسفانه یا خوشبختانه - همیشه حوصله‌مان از چیزهایی که جذابیتشان را برای ما از دست می‌دهند سر می‌رود.

همین مساله نشان می‌دهد که انسان در ناخودآگاه خود بیشتر تمایل به انجام ندادن کارها تا انجام دادن آن‌ها دارد.

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

در مقاله پیش‌رو «Lasse Kristensen» مثال خیلی جالبی را درباره این مقوله بررسی کرده.

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

http://bit.ly/dxgn586

(زمان حدودی مطالعه: ۸ دقیقه)

نویسنده: آرش اصغری

#دسترسی‌پذیری #تجربه‌کاربری

@Dexign فلسفه دیزاین


__

آیا اسکرام باعث کاهش اثربخشی توسعه‌دهندگان حرفه‌ای نرم‌افزار می‌شود یا این بخاطر بد اجرا شدن اسکرام است؟

اخیراً سؤالی در سایت Stack Overflow مورد توجه ما قرار گرفت. سوالی در خصوص تاثیر مخرب اسکرام بر روی اثربخشی توسعه دهندگان نرم‌افزار. این ادعا بسیار جنجالی است که اسکرام باعث می شود اثربخشی توسعه دهندگان عالی در حد توسعه‌‌دهندگان متوسط شود. آیا ادعا صحت دارد؟ یا فقط بخاطر اجرای بد اسکرام ما شاهد به‌وجود آمدن چنین فرضیاتی هستیم؟

نسخه کامل این داستان در پست زیر
https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/

@iranagile

❇️ کنترل سطح دسترسی پویا و Permission-based

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

هر کاربر میتونه N تا Role داشته باشه و هر Role هم N تا پرمیژن داره
پرمیژن ها در واقع Fullname اکشن هایی هستند که کاربر بهشون دسترسی داره مثلا
MyProject.HomeController.Index
مشخص میکنه کاربر به این اکشن دسترسی داره و وجود نام کامل متد باعث میشه مشکل هم نام بودن اکشن ها و کنترولر ها در پروژه های Microservice رو هم نداشته باشیم

مدیریت این قضیه هم کاملا توسط Reflection و Caching خیلی شیک انجام میشد و نیازی پرفرمنس بسیار خوبی هم داشت با توجه به اینکه تعداد کاربرانمونم زیاد بود، ضمن اینکه هیچ گونه کد نویسی ویا چک کردن سطح دسترسی لازم نبود توسط برنامه نویس انجام بشه و همگی در یک ActionFilter سراسری هندل میشد

قابلیت دیگه ای هم که نیاز بود و بهش اضافه کردیم بحث Group کردن اکشن های مرتبط بود. مثلا کاربری که دسترسی به ویرایش یک سند داره عملا به 3 اکشن Detail, Edit(Get) , Update(Post) x باید دسترسی داشته باشه، درنتیجه میتونستیم با اضافه کردن یک پرمیشن، 3 اکشن رو دسترسی داشته باشه

حتی واسه نیاز های پیچیده تر میتونین بحث Include و Exclude کردن یک یا چند پرمیژن رو از یک Role هم اضافه کنید. مثلا یک کاربر نقش Writer داره ولی... به یک اکشن از Report هم دسترسی داره (Include) و یا به یک اکشن خاص از نقش Writer نباید دسترسی داشته باشه (Exclude)
سلوشن بالا تمامی نیاز های مارو به خوبی برطرف کرد و کاملا راضی بودیم، برای پیاده سازیش هم میتونین از Identity یا هر پیاده سازی دلخواه برای احراز هویت استفاده کنید

🔸در کل ما 3 نوع کنترل سطح دسترسی داریم
سطح Api level (کنترل دسترسی به یک action/api خاص)
سطح Operation level (کنترل دسترسی به یک فرایند/بیزنس لاجیک خاص)
سطح Data level (کنترل دسترسی برای دیتای دریافتی از دیتابیس)

روش بالا برای کنترل دسترسی در سطح Action (همون Api level) هست و برای نیاز های دیگه کنترل دسترسی مثل کنترل دسترسی به یک فرایند خاص (Operation level) میتونین از مکانیزم ACL (مخفف access control list) استفاده کنید
برای کنترل دسترسی در سطح Data (همون Data level) برای کوئری گرفتن هم از Global Query Filter خود EF Core استفاده کنید
https://long2know.com/2017/05/entity-framework-multitenancy/
https://trailheadtechnology.com/entity-framework-core-2-1-automate-all-that-boring-boiler-plate/

🔹یه رویکرد دیگه که به نظر اصولی تر هم هست ولی یه کم تخصصی تره
بحث کنترل دسترسی در سطح Service ها توسط تکنیک AOP هست

مثلا این مقاله با CastleWindsor اومده قبل از اجرا شدن متد های سرویس، دسترسی کاربر رو چک کرده
https://lukemerrett.com/aop-in-castle-windsor/

از مزایای این روش میشه به این اشاره کرد که شما میتونین لایه سرویس (همون منطق تجاری پروژه) رو توی پروژه های دیگه هم به صورت مستقل استفاده کنید و نگران سطح دسترسی نباشید چون همش تو همون لایه داره چک میشه

🔸مدیریتش تو لایه Repsitory هم یک روش مرسوم هست
عملا استفاده از روش repository و Global Query Filter داره یک کار رو انجام میده
هر دو با شرط گذاشتن روی کوئری ها، دسترسی رو چک میکنن تنها تفاوت بینشون اینه که Global Query Filter این کار رو به صورت اتوماتیک انجام میده و دیگه لازم نیست موقع کوئری نوشتن حواسمون باشه که شرط فیلتر رو هم بگذاریم

و مزیتش دیگه اش هم اینه که موقع Explicit Loading (همون Include) و
حتی موقع Eager Loading (توسط LoadCollection و LoadReference) هم این موضوع به صورت خودکار چک میشه. توی EF 6 نبود این ویژگی. توی EF Core 2.0 اضافه شد

🔰این سری مقاله رو هم پیشنهاد میکنم بخونین، توضیحات خوبی در مورد روش های کنترل سطح دسترسی داده

Part 1: A better way to handle authorization in ASP.NET Core
https://bit.ly/2KaAo0q

Part 2: Handling data authorization in ASP.NET Core and Entity Framework Core
https://bit.ly/2KbA9SG

Part 3: A better way to handle ASP.NET Core authorization – six months on
https://bit.ly/2K8Z6hU

Part 4: Building a robust and secure data authorization with EF Core
https://bit.ly/2K885zH

#سطح_دسترسی #permission
___________________
@DotNetZoom

اصول طراحی جداول اطلاعات

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

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

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

http://bit.ly/dxgn587

(زمان حدودی مطالعه: ۱۰ دقیقه)

نویسنده: محمدرضا پناهی

#طراحی #جدول
@Dexign فلسفه دیزاین


______

داستان و‌ نمونه واقعی چابک سازی یک شرکت تولید ERP

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

https://www.agilealliance.org/resources/experience-reports/a-6-month-cultural-transformation-with-scrum/

@iranagile

۱۲ نکته در مورد Debugging در ویژوال استودیو:

در این پست فرض بر این است که خواننده اصول اولیه دیباگ کردن با ویژوال استودیو را می داند.

در صورتی که تسلط کامل بر روی این ۱۲ نکته داشته باشید، می توانید با کیفیت بالایی کد های خود را دیباگ کنید.

مواردی که در این پست به آن پرداخته شده است:

✅ 1) Run to Cursor : Ctrl+F10

✅ 2) Run through here with a mouse click

✅ 3) Set next statement to here : holding the key Ctrl

✅ 4) Data breakpoint: Break when value changes

✅ 5) Conditional breakpoint

✅ 6) Trace breakpoint

✅ 7) Track Objects that Are Out-Of-Scope : Make Object ID

✅ 8) View values returned by functions :
Debug > Windows > Autos

✅ 9) Reattach To Process: Shift+Alt+P

✅ 10) No-Side-Effect evaluation in Immediate Window and in the Watch Window

✅ 11) Show Threads in Source

✅ 12) Debug source code decompiled from IL code

جزئیات کامل را می‌توانید در لینک زیر مطالعه کنید:

https://blog.ndepend.com/12-visual-studio-debugging-productivity-tips/

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#حامد_حاجیلو (http://bit.ly/2IVjfYD)

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

___

❇️ خواهشا از HttpClient درست استفاده کنیم! (قسمت اول)

کلاس HttpClient محبوب ترین کلاس برای ارتباطات Http است ولی متاسفانه اکثرا از آن بدستی استفاده نمیکنند!
در این پست میخواهیم Best Practice های آن را بررسی کنیم.

در دات نت، 3 کلاس پایه برای ارتباطات Http داریم :

1️⃣ کلاس HttpWebRequest : اولین و low-level ترین کلاس که کنترل بیشتری به شما می دهد

2️⃣ کلاس WebClient : یک محصور کننده hight-level بر روی HttpWebRequest که کنترل کمتری به شما می دهد ولی طرز استفاده آن ساده تر است

3️⃣ کلاس HttpClient : بهینه ترین کلاس موجود برای ارتباطات Http که مزایای هر دو کلاس قبل را داشته و در دات نت 4.5 به بعد (و نیز تمامی ورژن های NETCore) اضافه شد (البته پکیج Nuget آن برای دات نت 4.0 هم وجود دارد)

کلاس HttpClient نسبت به دو کلاس قبلی پرفرمنس بیشتری داشته و متد های اصلی آن (از جمله GetAsync و PostAsync و...) thread-safe است درنتیجه میتوان یک نسخه از آن به صورت Singleton ایجاد و به صورت concurrent استفاده شود.

یک قابلیت مهم دیگر این آن، امکان Chain کردن HttpMessageHandlers ها در HttpClient است (چیزی شبیه به Pipeline میدلور ها در ASP Core) که میتوان از آن برای Logging، Caching و Error handling و ... استفاده کرد (مثال)

4️⃣ کتابخانه RestSharp نیز یک کتابخانه third-party برای ارتباطات Http و مخصوصا REST بوده ولی درون خود از HttpWebRequest استفاده میکند نه HttpClient و پرفرمنس کمتری دارد (نزدیک به نصف!)

5️⃣ کتابخانه Refit هم هست که با قابلیت های مدرن زیادی داره و کار با RESTful API ها رو خیلی راحت میکنه و البته از HttpClient هم استفاده میکنه (در حال حاضر بهترین کتابخانه third-party)

🔰 نکته بسیار مهم، استفاده بهینه و صحیح از این کلاس است که متاسفانه خیلی ها به اشتباه از آن استفاده میکنند

🔸کلاس HttpClient نباید هربار و به ازای هر درخواست، ساخته (new) شود که در این صورت پرفرمنس را به شدت کاهش میدهد!

🔹با وجود اینکه استفاده از یک شی Singleton آن نسبت به ایجاد هر باره آن بهتر است ولی باز هم صحیح نیست و باعث میشود از تغییرات DNS آگاه نشود!

🔸قبلا گفتیم که فقط متد های اصلی آن thread-safe است، پس پروپرتی های آن مانند (DefaultRequestHeaders و BaseAddress و Timeout و ...) thread-safe نیست و نباید بین ترد های مختلف به صورت مشترک استفاده شود
مثلا اگر یک شی Singleton یا static از HttpClient داشته باشید و در میان ترد های مختلف از آن استفاده کنید ممکن است در آن واحد که یک ترد در حال درخواست زدن به یک url است، ترد دیگری BaseAddress آن را تغییر دهد

🔹با وجود اینکه کلاس کلاس HttpClient یک شی Disposable است ولی نباید به صورت دستی Dispose شود درنتیجه استفاده از آن در کنار using (برای Dispose خودکار) به شدت اشتباه است و باعث مشکل حادی را به نام sockets exhaustion (اشباع سوکت های باز) میشود.

🔸نکته قبل، برای خروجی متد های آن، یعنی کلاس HttpResponseMessage صادق نیست و آن هارا باید حتما توسط using یا به صورت دستی Dispose کرد (البته در حالت دستی اگر exception ایی رخ دهد Dispose رخ نخواهد داد پس باید در بلاک try finaly نوشته شود)

🔹نکته بسیار مهم دیگر این است که به هیچ عنوان از کلاس HttpClient به صورت sync استفاده نکنید، ارتباطات network یکی از مهمترین عوامل block کننده thread بوده و دلیل اصلی اینکه کلاس HttpClient فقط و فقط دارای متد های async است همین بوده.
در نتیجه، استفاده از متد های آن به صورت sync همراه با Task.Wait و Task.Result به شدت اشتباه است و باعث بلاک شدن ترد می شود. (این مقوله برای تمامی متد های async صادق است و حتی می تواند باعث dead-lock شود)

در قسمت بعد اصولی ترین و بهینه ترین روش کار با HttpClient را بررسی خواهیم کرد.
#Performance #HttpClient
__________________
@DotNetZoom

❇️ خواهشا از HttpClient درست استفاده کنیم! (قسمت دوم)

در قسمت قبل روش های کار با Http و مزایا و معایب هرکدام را بررسی کردیم و به نکات و Best Practice های استفاده از HttpClient پرداختیم
در این قسمت میخواهیم بهترین روش استفاده از آن را بررسی کنیم

اصولی ترین و بهینه ترین حالت استفاده از HttpClient، استفاده از کلاس HttpClientFactory موجود در NET Core 2.1. به بعد است

این کلاس وهله سازی HttpClient و Dispose کردن آن را به صورت خودکار و استاندارد به عهده میگیرد و توسط مکانیزم Pooling (استخری از HttpClient ها) وهله های ایجاد شده را مجددا برای درخواست های بعدی استفاده می کند

بدین ترتیب HttpClientFactory از HttpClient های خود، به بهینه ترین نحو استفاده‌ی مجدد می‌کند و همچنین سربار ایجاد HttpClient‌های جدید نیز به حداقل می‌رسند.

در این روش دیگر مشکل نشتی حافظه یا کمبود منابع ناشی از Dispose نشدن HttpClient ها را نخواهیم داشت زیرا Lifetime وهله ها توسط HttpClientFactory مدیریت می شود
همچنین دیگر مشکل sockets exhaustion (اشباع سوکت های باز) و آگاه نشدن از تغییرات DNS را نخواهیم داشت

برای استفاده از این کلاس 4 روش موجود است
Basic usage
Named clients
Typed clients
Generated clients

روش Basic روش ساده و معمول آن است ولی معمولا در پروژه ها لازم است یک سری کانفیگ خاص را برای هر HttpClient تنظیم کنیم
مثلا HttpClient ایی که قرار است به سایت A درخواست بزند BaseAddress و Timeout و DefaultRequestHeaders (هدرهای پیشفرض) خود را دارد

از انجایی که این پروپرتی ها thread-safe نیستند بهترین راه استفاده از روش های Named clients و Typed clients است
نکته و محدودیت ای که در ورش Typed clients وجود دارد اینست که کلاس استفاده کننده از آن HttpClient الزاما به صورت Transient رجیستر میشود که باید مد نظر داشت و در صورت نیاز از روش Named clients یا ترفند های دیگر استفاده کرد.

روش Generated clients هم مخصوص استفاده از HttpClient توسط کتابخانه های third-party مانند Refit (که در قسمت قبل بررسی کردیم) است

برای یادگرفتن روش صحیح استفاده از HttpClient پیشنهاد میکنم حتما این 3 مقاله را بخوانید
https://www.dotnettips.info/post/2801
https://www.dotnettips.info/post/3022

https://docs.microsoft.com/en-us/aspnet/core/fundamentals/http-requests?view=aspnetcore-2.2


#Performance #HttpClient
_____________________
@DotNetZoom

انتخاب مناسب ویژگی‌های محصول بر اساس مدل کانو

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

مدل کانو یک نظریه توسعه محصول و رضایت مشتری است که در دهه ۱۹۸۰ توسط پروفسور نوریاکی کانو ساخته شده‌است. کانو در این روش اولویت‌های کاربران را به سه دسته پایه، جذاب و عملکردی طبقه‌بندی می‌کند. استفاده از این تکنیک با در نظر گرفتن دو فاکتور رضایت و احساس مشتریان، باعث درک بهتر دیدگاه کاربران در مورد ویژگی‎‌های مختلف محصول می‌شود. این فاکتورها به طراحان کمک می‌کند تا بفهند که کدام ویژگی محصول باعث ایجاد لذت و یا ناامیدی در کاربران می‌گردد.

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

http://bit.ly/dxgn598

(زمان حدودی مطالعه: ۸ دقیقه)

نویسنده: نیما‌ حکیم‌رابط

#مدل‌کانو #رضایت‌کاربر
@Dexign فلسفه دیزاین

___

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

بیشتر بخوانید در:
https://www.romanpichler.com/blog/feature-teams-vs-component-teams/

@iranagile

❇️ عیب یابی و رفع مشکلات پرفرمنسی

در یکی از شرکت هایی که مشاور هستم از من خواسته شده تا مشکلات پرفرمنسی پروژه را پیدا کرده و مناسب ترین راه حل را به آنها پیشنهاد دهم

در هر پروژه ای احتمالا قسمت های زیادی قابل بهبود هستند (چه از لحاظ پرفرمنسی و چه از لحاظ معماری و کدنویسی تمیز و...) اما برای یافتن موثر ترین راه و البته کم هزینه ترین، باید ابتدا Bottleneck (گلوگاه) های سیستم را کشف کرده و سپس بر اساس «هزینه، زمان و منفعت» آنها را الویت بندی کنیم

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

بهترین ابزار های Performance Profiler

1️⃣ برنامه ANTS Performance Profiler (محصول شرکت Redgate)
2️⃣ برنامه dotTrace (محصول شرکت JetBrains)
3️⃣ برنامه PerfView (محصولی "رایگان و سورس باز" از شرکت Microsoft)
4️⃣ برنامه CodeTrack (محصولی "رایگان و سورس باز")

هر چهار برنامه قابلیت های قوی و زیادی دارند از مهمترین شون میشه به موارد زیر اشاره کرد

🔸 قابلیت ثبت سلسله مراتب فراخوانی متد ها
توسط این قابلیت که اصلاحا بهش Call tree میگن میشه فهمید که چه متدی چه متد های دیگه ای رو فراخوانی کرده یا مثلا یک متد کلا چندبار صدا زده شده و هر متد چقدر به طول انجامیده (در قالب یک Timeline کامل) و ....

🔹 قابلیت ثبت تمام کوئری های اجرا شده بر روی دیتابیس
توسط این قابلیت میشه دید چه کوئری هایی و مثلا یک کوئری چندبار روی دیتابیس اجرا شده و هرکدوم چقدر زمان بره و...

🔸 قابلیت ثبت تمام Exception های رخ داده به همراه جزئیات و stacktrace

🔹 قابلیت نمایش تمام Thread های ایجاد شده و فرایند های انجام شده داخلش هر کدومشون و یا کلیه فرایند های انجام شده داخل یک Process

🔸 قابلیت پروفایل کردن همه برنامه ها از جمله
.NET Framework, .NET Core و ASP.NET, ASP.NET Core, Webservices, WCF, Windows Forms, Windows services, WPF ,IIS Website, IIS Express Website, Attach to a running process


❇️ این قابلیت ها برای عیب یابی به شدت مفید هستند چون توی یه سیستم با تراکنش بالا که بعضی مشکلات رو نمیشه پیش بینی کرد با این به راحتی میشه متد ها و یا کوئری های سنگین و اضافه ای که باعث افت پرفرمنس میشه رو پیدا کرد

❇️ هر دو برنامه ANTS و dotTrace پولی بوده و جز بهترین و محبوبترین برنامه های Performance Profiler هستند.
برنامه dotTrace یکپارچگی خوبی با Resharper داره و Visual Studio داره ولی شخصا با توجه به تجربه کاری با جفتشون، برنامه ANTS رو بیشتر می پسندم؛ کارکردن باهاش راحته و UX خوبی داره گزارشات و خروجی کاربردی تری نشون میده
ANTS Performance Profiler overview (ویدئو دمو برنامه)
https://www.youtube.com/watch?v=8mhC-Ji6-uU

❇️ برنامه PerfView هم تقریبا همین قابلیت ها رو داره ولی کارکردن باهاش سخت تره و UX خوبی نداره ولی چون رایگانه محبوبه
برنامه CodeTrack هم قابلیت هاش (نسبت به قبلی ها) کمتره ولی کارکردن باهاش راحته و UX متوسطی داره ونیز رایگانه

❇️ یه قابلیت خوبی که فقط dotTrace داره قابلیت Remote Profiling هست که توسط اون میتونین به برنامه هاتون روی یه سرور Remote دیگه متصل بشین و پرفایلش کنین

#Performance
____________________
@DotNetZoom

ساندویچ بندری، برای تیم‌های ریموت!

این عنوان موضوعیه که امروز (جمعه ۲۴ مراداد) ساعت ۵:۴۵ قراره در استیج @inotexevent در موردش صحبت کنم.
این صحبت یه جورایی ادامه سخنرانی پارسالم تو INOTEX 2019 با موضوع The Art of Thinking, But Together هست.

پس پیشنهاد می‌کنم قبلش از لینک زیر سخنرانی پارسال رو ببینید. مخصوصا اون قسمتش که در مورد دابل دایمند و «یه‌بل دایمند» صحبت می‌کنم!!
https://www.instagram.com/p/B-2kYQ4Ap9M/

استیج اینوتکس امسال به صورت مجازی برگزار می‌شه و می‌تونین از خونه و از طریق سایت inotex.com به عنوان مخاطب تو استیج باشین.

اسکن‌پذیری صفحات وب

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

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

۱- آیا چیزهایی که در اولین نگاه مشاهده می‌کنید، منطبق بر انتظارات کاربر است؟

۲- آیا می‌توانید در نگاه اول نوع اطلاعات موجود در صفحه را متوجه شوید؟

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

پیش از این، در مقاله زیر در مورد الگوهای اسکن اطلاعات صحبت کرده بودیم:

https://news.1rj.ru/str/Dexign/563

برای بهبود اسکن‌پذیری صفحات، رعایت نکات زیر مؤثر خواهد بود:

۱- اولویت‌بندی محتوا براساس سلسله‌مراتب بصری
۲- قرار دادن قسمت اصلی مسیر اطلاعات در هدر وبسایت
۳- حفظ تعادل فضای منفی
۴- مشاهده شدن دکمه‌های CTA در یک نگاه
۵- بررسی خوانایی محتوا
۶- استفاده از اعداد و ارقام به جای کلمات
۷- ارائه یک موضوع در هر پاراگراف
۸- استفاده از لیست‌های شماره‌گذاری شده و مشخص شده
۹- هایلایت کردن اطلاعات مهم
۱۰- استفاده از عکس و تصویرسازی

برای آشنایی بیشتر با این موضوع و نکات مؤثر، مقاله زیر را مطالعه کنید:

http://bit.ly/dxgn603

(زمان حدودی مطالعه: ۱۰ دقیقه)

نویسنده: محمدرضا پناهی

#اسکن‌پذیری #معماری‌اطلاعات
@Dexign فلسفه دیزاین

ـــــــــ

🍜۱۱ استراتژی برای رفع وابستگی مابین تیم‌های چابک

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

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

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

در ادامه ۱۱ استراتژی در خصوص مواجهه با این وابستگی ها معرفی شده است:

https://medium.com/@caminmccluskey/11-strategies-for-managing-dependencies-between-agile-squads-aac11e3c1f11

@iranagile

❇️ پیاده سازی راحت تر درگاه های پرداخت با Parbad

پرباد یه کتابخونه کاربردی و راحت جهت پیاده سازی درگاه های پرداخت هست و از ASP.NET CORE و AS.PNET MVC و ASP.NET WebForms پشتیبانی میکنه
این کتابخونه از انواع درگاه های زیر پشتیبانی میکنه، همچنین یه درگاه پرداخت تستی هم براتون میسازه که در زمان توسعه بتونین راحت تر پرداخت هاتون رو تست کنین.
✔️Mellat
✔️Melli
✔️Saman
✔️Pasargad
✔️Parsian
✔️Iran Kish
✔️Asan Pardakht
✔️ZarinPal
✔️Pay.ir
✔️IDPay.ir
🔰اینم اموزش فارسیش
https://www.dotnettips.info/post/3009
https://www.dotnettips.info/post/3011
https://www.dotnettips.info/post/3012
https://www.dotnettips.info/post/3013

🗂البته داکیومنت خودش بروز تره
https://github.com/Sina-Soltani/Parbad/wiki

https://github.com/Sina-Soltani/Parbad
____________
@DotNetZoom

قانون آشنایی جیکوب

الگوهای طراحی یا (Design Patterns) زمانی ایجاد می‌شوند که مدت زیادی را کاربران با آن رابط و تجربه‌ی کاربری مشغول هستند و بهترین راه‌حل ممکن را دریافت کرده‌اند.

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

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

bit.ly/dxgn607

(زمان حدودی مطالعه: ۵ دقیقه)

نویسنده: حسین میرزاده

#تجربه_کاربری #قانون_آشنایی_جیکوب #الگوی_طراحی

@Dexign فلسفه دیزاین

_____