موضوعی که در صحبت با تعدادی از دوستان معمارم مشاهده کردم این بود که آن‌ها Bounded Context در الگوی DDD رو با میکروسرویس هم ارز می‌دونن که اشتباهه.

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

https://martinfowler.com/bliki/BoundedContext.html

و همچنین مقاله زیر در خصوص این تفاوت توضیح نسبتا خوبی می‌دهد :

https://vladikk.com/2018/01/21/bounded-contexts-vs-microservices/


#شهریار_انتظام (https://ow.ly/qDN430nPiCg)

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

___

ویژگی‌های یک ارائه الهام‌بخش

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

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

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

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

در مقاله‌ای که برای معرفی آماده کرده‌ایم، آقای Christian Beck از چالش‌های ارتباط با مدیران کسب‌وکارها و شیوه‌های موثر در ارائه‌ی دیزاین یک محصول می‌‌‌گوید که برای تمام دیزاینرها می‌تواند مفید باشد.

https://bit.ly/dxgn538

شما با چه چالش‌هایی در ارتباط با مدیران پروژه مواجه شده‌اید؟ و چه روش‌هایی برای حل این مساله در نظر دارید؟
برایمان در بخش نظرات ✏️ بنویسید.

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

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

#مهارت_ارائه #دیزاین #الهام_بخش

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

___

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

ربات ۴ پای «اسپات»، حالا در اختیار برنامه‌نویسان!

حتما تا به حال ویدئوهای زیادی از ربات چهارپای شرکت Boston Dynamics که شبیه به یک سگ است دیده‌اید. رباتی که در شرایط سخت محیطی به خوبی قادر است حرکت کند و در شرایطی که ربات‌های «مبتنی بر چرخ» نمی‌توانند کار کنند این ربات به خوبی کار می‌کند.
حالا خبر جذاب این که شرکت بوستون داینامیکس یه نسخه تجاری از این ربات رو به اسم Spot داره وارد بازار می‌کنه. خبر جذذاب‌تر اینکه این ربات از طریق یک API قابل کنترل هست و در حقیقت دنیای جدیدی به دنیای برنامه‌نویسان اضافه شده!

در حال حاضر پروتکل ارتباطی این ربات از طریق gRPC است و این یعنی وااااااو! از این به بعد به مرور شاهد کاربردهای عجیبی از ربات‌هایی خواهیم بود که برنامه‌نویسان می‌تونن اونها رو کنترل کنند.

ویدئوی زیر، ویدئوی تبلیغاتی هست برای معرفی امکانات ربات اسپات ساخته شده. ببینید و لذت ببرید و آینده رو تصور و تجسم کنید!

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

https://youtu.be/wlkCQXHEgjA


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

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

___

داستان بخیه‌های ملک‌رادار

🌀یادداشت مهران داودی، مدیر عامل ملک‌رادار 👇


https://shanbemag.com/?p=29971

انجمن کاربران BSD ایران بستری است برای علاقه ‌مندان به BSD و UNIX تا گرد هم آیند و دانش و تجربیات خود را به اشتراک بگذارند.
ما در پنج‌شنبه آخر هر ماه نشست خواهیم داشت و از دیدار شما عزیزان نیز بسی شادکام و خرسند خواهیم شد.

دیدار نهم انجمن، پنجشنبه ۲۸ آذر ماه ۹۸، ساعت ۱۵:۰۰ تا ۱۸:۰۰ به میزبانی فضای کاری مشترک زاویه (zavie.co) برگزار خواهد شد.
با توجه به قوانین زاویه، برای سهولت کار نگهبانی و مدیریت مجموعه، اسامی شما دوستان باید پیش از گردهمایی برای ایشان ارسال شود. لذا خواهشمند است نام خود را در صورت تمایل برای حضور به نشانی [email protected] ارسال کنید و یا در صورت دشواری برای ارسال ایمیل، با اینجانب به شناسه کاربری @kfvahedi پیام دهید.

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

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

به امید دیدار شما عزیزان،
مدیریت انجمن کاربران BSD ایران

صداست که می‌ماند...

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

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

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

https://bit.ly/dxgn539

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

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

#برندینگ #صدا #هویت_برند
@Dexign فلسفه دیزاین

___

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

چطور در دنیای نرم افزار بهتر دیده شوید

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

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

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

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

فقط لازم است بدانید چطور از این ابزار درست استفاده کنید.

https://youtu.be/AN7QuLDVylc

#امیرحسین_عبدالخالق (https://bit.ly/2n025Rz)

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

___

EXACT INSTRUCTIONS

پیشنهاد می‌کنم اول فیلم رو ببنید بعد بقیه مطلب رو بخونید.

https://www.youtube.com/watch?reload=9&v=Ct-lOOUqmyY

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

یکی از مهم‌ترین کارهایی که باید توی شرکت‌های نرم‌افزاری به درستی انجام بشه، داکیومنت کردن است. (داکیومنت به معنی کامنت گذاشتن داخل کد اصلا منظورم نیست، کد باید خودش به قدری خوانا باشه که نیاز به کامنت نداشته باشه یا به اصطلاح Self-Document باشه.)
داکیومنت کردن رو نباید به عنوان یه کار اضافه دید و سرسری انجامش داد.
تمام مراحل انتقال دانش باید به وسیله داکیومنت انجام بشه. نه به صورت نقل قول و سینه به سینه.

اتفاقی که برای خودم افتاد رو براتون تعریف می‌کنم:
در شرکت کرانه ادمین TFS بودم، و یکی از کارهایی که باید انجام می‌دادم و داکیومنت می‌کردم Disaster Recovery خود TFSبود. ۱ روز کامل وقت گذاشتم و Recovery رو انجام دادم و داکیومنتش رو نوشتم، کاری که مدیرمون کرد خیلی خوب بود. داکیومنت رو داد به یکی دیگه گفت TFS رو بیار بالا. حدس می‌زنید چی شد؟ نتونست، چون داکیومنتی که نوشته بودم به درد خودم می‌خورد.
و حرفی که به من زد این بود «داکیومنت باید طوری باشه که اگه دست یه نفر رو از توی خیابون گرفتم و این داکیومنت رو بهش دادم بتونه TFS رو بیاره بالا». بعد از ۳ بار داکیومنت نوشتن بالاخره موفق شدم داکیومنتی بنویستم که به هر کی بدمش فقط با Back up دیتا بیس بتونه TFS رو بالا بیاره.

به نظر من داکیومنت باید طوری باشه تا تمام کسانی که می‌خوننش، همشون یک برداشت رو داشته باشن، داکیومنت نباید وابسته به Context ذهن ما باشه.

خوشحال می‌شم نظر شما رو هم بدونم.

#افشین_علیزاده (https://ow.ly/l7cA30m3OQ9)

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

___

تو ریپوی vscode یکی یه ایشو زده که کلاه سانتا رو گذاشتین به ما یهودیا بر خورده.. اونام برداشتن کلاه رو...
حالا ملت اومدن همینطوری ایشوهای خنده‌دار زدن. مایکروسافت مجبور شده فعلا کلا امکان ایشو زدن رو ببنده :)))))

- چرا تم سفید بالاتر از تم مشکیه، به ما رنگین پوستا بر می‌خوره!
- چرا می‌گین باگ، به حشرات بر می‌خوره!
- تم مشکی (black) رو حذف کنین، به من خیلی بر می‌خوره!
- من تو سیبری زندگی می‌کنم، اینجا خیلی سرده، چرا کلاه رو برداشتین به من خیلی بر خورد!
- من برنامه‌نویس نیستم و کلمه code بهم بر می‌خوره!
- بقیه کامنتا رو هم بخونین بامزن ...

https://github.com/microsoft/vscode/issues?page=1&q=is%3Aissue+is%3Aclosed+label%3A%2Aoff-topic

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

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

___

همراه کردن مخاطب در درک دیزاین

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

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

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

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

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

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

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

https://bit.ly/dxgn540

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

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

#مخاطب #دیزاین #مشتری
@Dexign فلسفه دیزاین

___

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

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

در لینک زیر توضیحات بیشتری در این مورد وجود داد :

https://www.edureka.co/blog/what-is-jenkins/

#شهریار_انتظام (https://ow.ly/qDN430nPiCg)

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

___

🔵 🔵 تیری به قلب SAFe؟! چرا وزارت دفاع آمریکا رسماً اعلام کرد که نباید از چارچوب SAFe استفاده کرد؟

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

شواهد متعدد نشان می‌دهد که ارتش و بخصوص وزارت دفاع ایالات‌متحده در مسیر چابکی بیشتر برای توسعه نرم افزارهایش، قصد تغییر و پذیرش یکی از این چارچوب‌ها را داشته است و منجر به آن شد که آقای نیکولاس چِیلان – Nicolas M. Chaillan، افسر ارشد نرم‌افزار و مسئول پروژه DevSecOps در نیروی هوایی ایالات‌متحده، در قالب یک گزارش جامع، علاوه بر پوشش سوالات و چالش‌های نرم‌افزاری متنوع، بخشی را نیز به بیان دیدگاه خود و گروهش نسبت به استفاده از چارچوب‌های مقیاس‌پذیر به‌ویژه چارچوب SAFe در سازمان متبوعش اختصاص دهد.

انتشار این گزارش بسیار مهم، واکنش‌های بین‌المللی فراوانی را در پی داشته است. برای اینکه اهمیت این موضوع را بهتر درک کنید باید خاطرنشان کنم که مطالعه جنبش‌ها و تحولات تاریخی در صنعت نرم‌افزار نشان می‌دهد که ارتش‌های جهان به‌طور کل و وزارت دفاع و ارتش ایالات‌متحده آمریکا به‌طور خاص، همواره منشأ و خاستگاه انواع ابتکارات، چارچوب‌ها، مفاهیم، فرایندها، تکنیک‌ها و تاکتیک‌های عمدتاً خوب و گاهی هم نچندان خوب بوده‌اند!
👉 https://vrgl.ir/9PP8H

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

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

🔗 https://virgool.io/@soheilsam/ym1ehfl3sanh

✅ آپلود فایل های بسیار حجیم در ASP.NET Core

واسه فایل های نه چندان حجیم (مثلا تا 200 الی 300 مگابایت) میتونین از 2 آموزش زیر استفاده کنین که ترفنداشو بهتون میگه

https://www.binaryintellect.net/articles/612cf2d1-5b3d-40eb-a5ff-924005955a62.aspx

https://www.talkingdotnet.com/how-to-increase-file-upload-size-asp-net-core/

🔰 ولی اگه فایل هاتون خیلی حجیم هست (مثلا 500 مگ به بالا تاااااا چندین گیگابایت)
بهتره از روش Chunk (خرد کردن فایل حجیم به تکه های کوچیک تر و سپس آپلود این تیکه ها و نهایتا جمع کردنش سمت سرور) استفاده کنین

🔸سمپل زیر این قابلیت رو به خوبی پیاده سازی کرده
واسه این روش باید هم سمت سرور کدشو بنویسین و هم سمت کلاینت، از پلاگینی استفاده کنین که کار Chunk کردن رو براتون انجام بده (البته دستی هم میشه ولی با پلاگین راحت تره) مثلا این سمپل از پلاگین Resumable.js استفاده کرده

https://github.com/edsoncunha/chunked-file-upload-csharp
نکته : واسه اجرا حتما برنامه رو روی Kestrel اجرا کنین وگرنه در حالت IISExpress محدودیت هایی داره
_______________
@DotNetZoom

دیزاین به مثابه جاده چالوس

دیزاین تنها یک شغل نیست. اشتباه است اگر فکر ‌کنیم که دیزاینرها پشت میز کارشان می‌نشینند و تمام روز مشغول طراحی با ابزارهای دیجیتال هستند یا آنکه برای دیزاینر شدن تنها کافیست که بر ابزارهایی همچون ادوبی XD، ایلاستریتور، فتوشاپ یا اسکچ تسلط پیدا کنیم.

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

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

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

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

https://bit.ly/dxgn541

به نظر شما یک طراح چه مهارت‌های دیگری را باید در خود تقویت کند؟ پاسخ خود را با کلیک روی گزینه «نظرت را بگو✏️» با ما در میان بگذارید.

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

نویسنده پریسا حسینی

#مهارت_نرم #تجربه_کاربری #دیزاین

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

___

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

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

https://leanstartup.co/12-tips-for-managing-a-remote-team-and-loving-it/

#مریم_کمالی (https://ow.ly/9Wa430mFGeK)

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

___

اسکرام مسترها در طول هفته چه کار می‌کنند؟ این سوال بسیاری از اسکرام مسترها است. به تازگی طی نظرسنجی موارد زیر بیشترین فعالیتهایی بود که آنها انجام میدادند:

🌐 به طور میانگین هر هفته اسکرام مستر مشغول فعالیتهای زیر است:

⁦✍️⁩ Product Backlog refinement: 1.00 hours/week

⁦✍️⁩ Sprint Planning: 0.75 hours/week

⁦✍️⁩ Daily Scrum: 1.50 hours/week

⁦✍️⁩ Sprint Review: 0.50 hours/week

⁦✍️⁩Sprint Retrospective: 0.75 hours/week

⁦✍️⁩ Learning: 2.00 hours/week

⁦✍️⁩Training of teammates: 3.00 hours/week

⁦✍️⁩Training of stakeholders: 2.00 hours/week


گزارش کامل
https://berlin-product-people.com/scrum-master-duties/

@iranagile

❇️ آموزش ساخت برنامه های توزیع شده (Distributed) توسط Akka.NET (زبان اصلی زیر نویس دار)

از پایین ویدئو گزینه [Subtitle/captions] میتوانید زیرنویس آن را فعال کنید

مدل Actor به عنوان یک مدل Messaging برای برنامه‌نویسی توزیع شده و همزمان در مقابل استفاده از Thread ها به حساب می‌آید.
فریمورک Akka برای استفاده از مدل Actor در زبان Java طراحی شده و Akka.NET فریمورک Port شده آن برای دات نت است.
(اطلاعات بیشتر : Repository - Document)
توسط این فریمورک میتوان برنامه هایی با پرفرمنس و همزمانی بالا را بدون اینکه صراحتا درگیر مدیریت تردها و قفل گذاری شوید بنویسید


[01:35] - Implementations and uses of the actor model
[03:13] - What is an actor?
[10:04] - Actors in the cloud
[12:05] - Running Akka .NET on premise or in cloud
[14:31] - Use cases for Akka .NET
[17:25] - Supported versions of .NET
[18:45] - Running Akka .NET in containers

Useful Links
Petabridge - (Repository)
Akka .NET on GitHub
Akka .NET Bootcamp
Akka .NET Code Samples
____________
@DotNetZoom