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

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

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

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

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

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

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

https://youtu.be/AN7QuLDVylc

#امیرحسین_عبدالخالق (http://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 ذهن ما باشه.

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

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

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

___

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

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

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

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

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

___

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

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

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

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

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

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

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

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

http://bit.ly/dxgn540

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

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

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

___

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

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

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

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

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

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

___

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

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

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

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

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

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

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

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

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

http://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 مهارت‌های نرمی که لازم است هر طراح به آن مجهز باشد را معرفی می‌کند و ضرورت هر کدام را توضیح می‌دهد.

http://bit.ly/dxgn541

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

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

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

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

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

___

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

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

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

#مریم_کمالی (http://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

کلاه سانتا (Santa Hat)

ضمن تبریک سال نو میلادی به همه‌ی دوستان، در راستای این پست در کانال Software Philosophy و طبق صحبتی که با جناب #آقای_داوودی گرامی شد، قرار بر این شد که در راستای نشر مشکل اتفاق افتاده راه حل اتخاذ شده برای این قضیه رو هم نشر بدیم.

درباره‌ی این‌که داستان دقیقا چی بوده می‌تونید به 7 دقیقه‌ی اول از این podcast جناب #آقای_قدس عزیز در کانال Codehaks گوش بدید. اما به طور خیلی خلاصه دقیقا مشابه همین کلاهیه که اگر تلگرامتون رو به‌روز رسانی کرده باشین در این ایام روی نام Telegram در صفحه‌ی اصلیش می‌بینید، که حالا فرض کنید به دلایلی، شخصی اون رو توهین آمیز قلمداد کنه.

حالا که می‌دونید داستان از چه قرار هست، ببینیم واکنش #مایکروسافت (#Microsoft) به این قضیه به چه صورت بوده؟

در واقع همون‌طور که خودشون هم گفتن با وضعیت بسیار حساس و سختی مواجه بودن، چون با هر واکنششون واکنش‌های بیش‌تری رقم می‌خورده، و هم‌چنین از طرفی دیگه تعدادی از افراد آزرده خاطر می‌شدن. هم‌چنین تا حد ممکن سعی داشتن تا چیزی رو سانسور نکنن، حتی برخی از Commentها و Issueهایی که خارج از آیین نامه‌ی اخلاقی یا همون Code of Conductاشون بوده، و همون‌طور که توی پست و podcast که در بالا بود، عنوان شد به دلیل شوخ طبعی کاربران Issueهای Spam اونقدری زیاد شده بوده که مجبور به قفل کردن Repository شدن!

البته که بر مبنای نظام نامه اخلاقیشون (Code of Conduct) حق حذف Issueها و Commentهایی رو که بنا به تشخیص خارج از ضوابط بود رو داشتن اما از طرفی نمی‌خواستن سانسور رو بر روی همه‌ی اون‌ها اعمال کنن و قصد داشتن فقط موارد بحرانی‌تر رو حذف کردن، در واقع به طور خلاصه این دستورالعمل رو پیاده کردن:

1️⃣ برچسب جدیدی با نام *off-topic ساختن و Issueها رو باهاش Tag کردن، که باعث شد ربات مربوطه (که رده بندی‌ها رو انجام می‌داد) اون Issue رو ببنده و این قضیه منجر به این شد که راحت‌تر و سریع‌تر با Backlogها سر و کله بزنن.
2️⃣ اگر Issue توسط یکی از افراد تیم بسته شده بود برچسب *off-topic رو بهش اضافه کردن و دلیل بسته شدنشون رو به طور دستی ثبت کردن.
3️⃣ برای این‌که کاربرا بتونن ببینن چه چیزهایی بسته شده، Issueها رو باز گذاشتن و تصمیم گرفتن فقط وقتی قفلش کنن که نظام نامه اخلاقیشون رو نقض کن.
4️⃣ تعداد کمی از Commentها و Issueهایی که بیش از حد توهین آمیز بودن رو به طور کلی حذف کردن

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


البته بد نیست بدونید این اولین باری نبوده که چنین مشکلی پیش میاد. در واقع در سال 2011 در مورد پروژه VLC (که یک Player هست) به خاطر این تغییر شخصی در Forum مربوطه اعتراض کرد. اما در اونجا شخصی از رهبران توسعه‌ی تیم خیلی مستقیم بهش گفت: «اگر نمیخوای می‌تونی از VLC استفاده نکنی!» که خوب این برخورد باز خودش برای بعضی‌ها توهین آمیز بود. اما برخی معتقدن مایکروسافت هم می‌تونست هم‌چنین برخوردی رو کنه و هم خودش رو راحت‌تر کنه، هم به خاطر حرف یک شخص، عقیده بسیاری اشخاص دیگه رو ندیده نگیره. اما خوب شاید اصرار به میانه روی و تعادل مایکروسافت و یا همون جمله‌ی گفته شده در متن که: «مورد اهانت قرار گرفتن حتی یک نفر هم می‌تونه زیاد باشه!» بیش‌تر خودش رو به سختی انداخت، که البته سر آخر ارزششو داشت و به رضایت نسبی بیشتری دست پیدا کرد.

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

برای این‌که به طور دقیق‌تر و جزیی‌تر راجع به این قضیه مطالعه کنید می‌تونید به لینک زیر سر بزنید:
https://github.com/microsoft/vscode/issues/87440
#WroteBy <Chris Dias>
#Date <23 Dec 2019>

References
https://github.com/microsoft/vscode/issues/87440
https://linuxreviews.org/Microsoft_Removes_Christmas_Hat_from_MIT_Licensed_VS_Code,_Closes_Issue_Tracker_To_Silence_Complaints
https://forum.videolan.org/viewtopic.php?t=96539
https://news.ycombinator.com/item?id=21833377
https://t.me/SoftwarePhilosophy/1832
https://t.me/codehaks/919

#SantaHat
#VSCode
#Fun
#Solution

by @D4NTESPARDA
@ProgrammingLanguages

تفکر خارج از چارچوب

در فضای کاریمان شاید بارها و بارها این کلیشه‌ی معروفِ “تفکر خارج از چارچوب یا (thinking out of the box)" شنیده‌ایم. امّا هنگام مواجه شدن با یک چالش جدید، باز هم درگیر همان چارچوبی هستیم که قبلا با آن مشکلات را حل کردیم. امّا قبل از اینکه به این موضوع بپردازیم که چطور می‌توانیم خارج از این زندان ذهنی بیاندیشیم به تاریخچه‌ی کوتاهی ازین اصطلاح می‌پردازیم که کمک کننده است.

از ویکیپدیا:

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

پازل ۹ نقطه ای چیست؟

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

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

http://bit.ly/dxgn542

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

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

#تفکر_خارج_از_چارچوب #روش_شناسی #چالش

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

___

تفاوت بین Site Reliability Engineering و Engineering DevOps مطلب جالبی‌ست. با آنکه با هم تفاوت دارند اما شبیه به هم هستند. اگر بخواهیم با دنیای OOP مقایسه کنیم SRE شبیه کلاس‌ها است و DevOps شبیه اینترفیس‌ها . SRE روابط بین دپارتمان‌های تولید و عملیات را به لحاظ همکاری و به اشتراک گذاری داده ها تنظیم می‌کند .

لینک زیر تفاوت این دو را به خوبی بیان می‌کند :

https://www.bmc.com/blogs/sre-vs-devops/

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

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

___

چگونه در یک شرکت پروژه محور، محصول محور باشیم؟

یکی از مشکلات اساسی که شرکت‌های نرم افزاری با آن مواجه هستند، شتر گاو پلنگ بودن میان دو دنیای پروژه محوری و محصول محوری است.
در دنیای پروژه محور ما از اول به دنبال یک “زمان و برنامه” هستیم: 1- چه زمانی کار به اتمام می رسد 2- برنامه دقیق اجرا چیست؟ تا بعد آن یک واحد نظارتی دیگر بر اساس این برنامه و زمان اعلام شده ، پیشرفت پروژه را ارزیابی کند. در نگرش پروژه محور، سوال همیشگی این است "چه زمانی تمام می شود"، بخاطر همین همیشه اصلی ترین چالش شیوه تخمین زدن زمان پروژه است.
اما در دنیا محصول محور، یک محصول تا زمانی که برای مشتری/شرکت ارزش خلق کند زنده خواهد ماند و تا هر زمانی که زنده است، توسعه ادامه خواهد داشت(چرخه عمر محصول).
فرض کنیم، نرم افزاری مانند اینستاگرام را بخواهیم پروژه در نظر بگیریم که یک شرکت پیمانکار از شرکت فیسبوک گرفته تا انجام دهد، احتمالا در نظام مدیریت پروژه سوال این است که “کی این پروژه تمام می شود؟ ساختار شکست کار به چه صورتی است؟”

ادامه نوشته
http://vrgl.ir/PLf8F

@iranagile

❇️ یک پروژه FullStack سورس باز SPA با Angular 8 و Asp.Net Core 3.1

🔰 تکنولوژی ها و امکانات :
✔️ASP.NET Core 3.1
✔️Entity Framework Core 3.1
✔️Both Sql Server and Sql lite databases are supported
✔️Identity Server 4
✔️Angular 8
✔️Angular CLI 8
✔️Secure - with CSP and custom security headers
✔️SignalR
✔️SASS
✔️Best practices for Angular code organisation.
✔️Clean Architecture for ASP.Net Core code.
✔️PWA support
✔️SSR (Server side rendering)
✔️Fast Unit Testing with Jest.
✔️E2E testing with Protractor.l
✔️Compodoc for Angular documentation
✔️Login and Registration using Identity Server implicit flow
✔️Extensible User/Role identity implementation
✔️Social logins support with token based authentication
✔️Swagger as Api explorer

🔸 مخزن گیتهاب
https://github.com/asadsahi/AspNetCoreSpa
_____________________
@DotNetZoom

موفقیت با رمز یکپارچگی

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

این ویژگی یکپارچگی (Consistency) نام دارد و باعث می‌شود کاربر برای استفاده از محصول یا سرویس نیازمند یادگیری اصول و قواعد جدید نباشد و همچنین هنگام استفاده از آن دچار سردرگمی نشود.

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

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

http://bit.ly/dxgn543

به نظر شما توجه به چه نکاتی در حفظ یکپارچگی محصول مؤثر است؟ نظرات خود را با ما در میان بگذارید.

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

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

#یکپارچگی #تجربه_کاربری #طراحی_محصول

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

ـــــــــــــ

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