ولی روی کامپیوتر من کار می‌کنه ...؛ خاطرات قبل از Angular9

زمانیکه به عنوان frontend developer در کنار چند نفر از دوستان دیگر کار می‌کردم، یکی از قوانین کاریمان این بود که قبل از git push کردن تغیرات، حتما برنامه را در مود production، نیز اجرا و تست کنیم. اما چرا اینکار لازم بود؟

پاسخ در این نکته است، که انگولار ورژن 8، بسته به روش کامپایل (JIT یا AOT)، توانمندی متفاوتی در type checking در template file ها داشت. محیط توسعه از JIT استفاده می‌کرد و محیط deployment از AOT. اینگونه بود که روی کامپیوتر من کار می‌کرد و بعد از دیپلوی شدن نه!

از ورژن 9 به بعد، دستورات ng build و ng serve نیز از Ahead Of Time Compilation استفاده می‌کنند، این امر کمک می‌کند در حین بیلد در زمان توسعه،متوجه باگ‌هایی شویم، که تا پیش از این تا زمان کامپایل در مود production نادیده گرفته می‌شدند.

این همه‌ی داستان نیست، قابلیت Strict Templates در انگولار ورژن 9، می‌تواند باگ‌هایی را در زمان build پیدا کند، که تا قبل از این نسخه، حتی در مود production نیز، از چشم پنهان می‌ماندند. اما برای استفاده از این قابلیت جدید (Strict Templates) علاوه بر آپگرید به ورژن 9 و بالاتر، باید کانفیگ کامپایلر انگولار را نیز ویرایش کنید. کافی است در فایل tsconfig، تنظیمات زیر را به کانفیگ کامپایلر انگولار اضافه کنید:

"angularCompilerOptions": {
    "strictTemplates": true,
    "strictInjectionParameters": true
  }

مقاله زیر از John Papa با بررسی چند سناریو، مزیت استفاده از قابلیت Strict Template در انگولار 9 را نشان می‌دهد.

Angular 9's Best Hidden Feature: Strict Template Checking (auth0.com)

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

#شهریار_سلجوقی (لینکدین)

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

________

گاف‌های مدیران محصول شرکت‌های معتبر

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

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

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

https://bit.ly/dxgn662

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

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

#مدیریت‌محصول #اشتباهات
@Dexign فلسفه دیزاین

_____

مقایسه تکنولوژی استفاده شده در شرکت های بزرگ برنامه نویسی دنیا

توسط این سایت می توانید بهترین تکنولوژی، ابزار ها و فریمورک های مورد استفاده در شرکت های بزرگ برنامه نویسی دنیا را مشاهده و با یکدیگر مقایسه کنید.
https://stackshare.io/

مثلا لینک زیر تکنولوژی ها و ابزاری های مورد استفاده در شرکت Airbnb را نمایش می دهد.
https://stackshare.io/airbnb/airbnb
___________
@DotNetZoom

🎯 مربی چابک، با شیفت تیم و شرکت، خودش نیز باید شیفت پیدا کند

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

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

داستان کامل را در لینک زیر مطالعه کنید 👇👇👇


https://www.agilealliance.org/resources/experience-reports/the-changing-role-of-the-agile-coach/

@iranagile

چگونه طرح خود را ارائه کنیم؟ و بتوانیم به خوبی از آن دفاع کنیم.

هر طراح محصول باید بتواند محصول خود را به مشتریان یا مدیران ارائه کند. اما اسرار ارائه موفق محصول چیست؟

ارائه طراحی چیست؟

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

درک ارائه برای طراحان

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

برای کسب اطلاع در مورد جنبه‌های مختلف یک ارائه موفق، همراه ما در ادامه‌ی این مقاله باشید!

https://bit.ly/dxgn671

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

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

#ارائه #طراح‌محصول #محصول #کاربر

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

_______

❇️ معرفی چندین پروژه Starter Template برای ASP .NET Core و React - Vue - Angular

🔰پروژه های ASP .NET Core + React
▪️https://github.com/bradymholt/aspnet-core-react-template
ASP.NET Core 3.1 / React SPA Template App
▪️https://github.com/NickMaev/react-core-boilerplate
Powerful ASP.NET Core 3 templates with React, true server-side rendering and Docker support
▪️https://github.com/CodAffection/React-CRUD-with-Asp.Net-Core-Web-API
Full Stack React js CRUD with Asp.Net Core Web
▪️https://github.com/microsoft/AspNetCore-React-WebApp
ASP.NET Core backend + React frontend + Entity Framework Core + automated testing
▪️https://github.com/based-ghost/aspnet-core-react-redux-playground-template
SPA template built with ASP.NET Core 5.0 + React + Redux + TypeScript + Hot Module Replacement (HMR)
▪️https://github.com/NetCoreTemplates/react-spa
.NET 5.0 React Create App CLI Bootstrap App


🔰پروژه های ASP .NET Core + Vue
▪️https://github.com/TrilonIO/aspnetcore-Vue-starter
Asp.net Core & Vue.js (ES6) SPA Starter kit - Vuex, webpack, Web API, Docker, and more!
▪️https://github.com/SoftwareAteliers/asp-net-core-vue-starter
ASP.NET Core + Vue.js starter project
▪️https://github.com/danijelh/aspnetcore-vue-typenoscript-template
Template AspNetCore with Vue, Vue router, Vuex, TypeScript, Bulma, Sass and Jest
▪️https://github.com/NetCoreTemplates/vue-spa
.NET 5.0 Vue CLI Bootstrap App
▪️https://github.com/damienbod/AspNetCoreMvcVueJs
ASP.NET Core with Vue.js
▪️https://github.com/based-ghost/aspnet-core-vue-vuex-playground-template
SPA template built with ASP.NET Core 5.0 + Vue + Vuex + TypeScript + Hot Module Replacement (HMR)


🔰پروژه های ASP .NET Core + Angular
▪️https://github.com/TrilonIO/aspnetcore-angular-universal
ASP.NET Core & Angular Universal advanced starter - PWA w/ server-side rendering for SEO, Bootstrap, i18n internationalization, TypeScript, unit testing, WebAPI REST setup, SignalR, Swagger docs, and more!
▪️https://github.com/emonney/QuickApp
ASP.NET Core 3.1 / Angular 9 startup project template with complete login, user and role management. Plus other useful services for Quick Application Development
▪️https://github.com/FabianGosebrink/ASPNETCore-Angular-Ngrx
An ASP.NET Core WebAPI Demo with an Angular Client using Ngrx store and effects and Signalr
▪️https://github.com/jasontaylordev/SecureSpa
ASP.NET Core 3 + Angular 8 + ASP.NET Identity generated using .NET Core SDK
▪️https://github.com/DanWahlin/AngularCLI-ASPNET-Core-CustomersService
Example of integrating Angular with ASP.NET Core RESTful Services
▪️https://github.com/NetCoreTemplates/angular-spa
.NET 5.0 Angular 9 CLI Bootstrap App

________________
@DotNetZoom

تیم من "ایده های " من رو قبول نمیکنه

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

اما چه باید کرد؟

1- باهم ایده ها را خلق کنید
2- حضور داشته باشید، از روی ضعف با دیگران ارتباط نگیرید، مثلا "دائم، در حال عذرخواهی از دیگران نباشید..."
3- داستان گویی کنید

توضیحات بیشتر در مورد هر کدام از این موارد در لینک زیر 👇👇

https://www.lennysnewsletter.com/p/getting-buy-in

@iranagile

کار در وضعیت ویژه

ماه‌هاست که وضعیت ویژه‌ای بر جهان حاکم است. مشخصا درباره بیماری کرونا صحبت می‌کنم.

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

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

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

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

خواندن این مقاله به هرکسی که ریموت کار می‌کند پیشنهاد می‌شود.

http://bit.ly/dxgn682-1

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

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

#ریموت #تجربه_کاربری

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

______

آموزش کار با CSS Isolation در ASP NET Core 6.0

https://youtu.be/kqdn7dzEyhk

ژاپن برای واکسیناسیون کوید-19 از متد تویوتا استفاده می‌کند

متد تویوتا در واقع راه روش شرکت خودروسازی تویوتا است که در کشورهای غربی معمولا با عنوان ناب شناخته می شود. در واقع اساس این متد بر از بین بردن اتلافات و افزایش بازدهی هست. بازدهی که در راستای خلق ارزش هست، مثلا انتظار کم برای کسانی که میخواهند واکسن بزنند.

اینکه چگونه این متد برای افزایش بازدهی طرح واکسیناسیون استفاده شده بسیار جالب هست

https://mainichi.jp/english/articles/20210609/p2a/00m/0bu/022000c

@iranagile

اختیار از دست رفته؛
چگونه محصولات دیجیتال را انسانی‌تر کنیم!

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

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

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

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

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

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

http://bit.ly/dxgn693-1

http://bit.ly/dxgn693-2

http://bit.ly/dxgn693-3

(زمان حدودی مطالعه‌ی مقاله‌‌ی اول‌‌: ۱۷ دقیقه،
مقاله‌ی دوم: ۸ دقیقه
و مقاله‌ی سوم: ۱۰ دقیقه)

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

#تجربه_کاربری #روانشناسی #تکنولوژی #دیزاین_اخلاقی #انسان_محور

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

______

مقایسه رفتار Thread Pool در متدهای Sync و Async

https://youtu.be/AdauMu7fpkI

هفت نکته مهم برای تصمیم های بهتر محصول

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

1- باید بدانیم چه زمانی تیم توسعه و ذینفعان را در تصمیم گیری مشارکت بدهیم: اصولا همیشه لازم نیست هر تصمیمی به صورت مشارکتی گرفته شود، تشخیص زمان درست بسیار مهم است. از بعد اجرایی، ذینفعان و تیم های توسعه دهنده را در تصمیماتی که بر استراتژی محصول و نقشه راه محصول تأثیر می گذارد، درگیر کنید.

2- افراد درست را دوره هم جمع کنید: برخی مواقع ما تصمیم جمعی با افراد اشتباه می‌گیریم

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

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

5- در مورد شیوه تصمیم گیری توافق کنید، 1- اتفاق نظر: همه با راه حل پیشنهادی موافق هستند و از تأیید آن خوشحال هستند. 2- رضایت: هیچ کس اعتراض معناداری ندارد. 3- اکثریت: بیش از نیمی از افراد ملزم به توافق با راه حل پیشنهادی هستند. 4- متخصص محصول پس از شنیدن بحث، تصمیم می گیرد: هنگامی که همه شنیده شدند و درک مشترکی از ایده های مختلف ایجاد شد، مثلا مدیر محصول تصمیم می گیرد.

6- برای تصمیم های مهم عجله نکنید، شاید در چند جلسه این تصمیم گیری باید انجام شود.

7- از دیتا بعنوان پشتیبان تصمیم گیری استفاده کنید. داده های مرتبط را جمع آوری کنید و از آنها برای تصمیم گیری استفاده کنید.

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

https://www.romanpichler.com/blog/tips-for-deciding-with-stakeholders-and-dev-teams/

@iranagile

سیستم‌هایی پویا برای تحول تیم

سیستم‌های طراحی (Design System) مدت‌هاست که وجود دارند، این سیستم‌ها نه فقط برای طراحی یک مورد خاص بلکه برای طراحی مجموعه‌ای کامل از عناصر با حفظ یکپارچگی ظاهر و حس آن‌ها به‌وجود آمده‌اند.
دیزاین سیستم‌ها ابتدا به عنوان راهنمای استانداردی برای اسفتاده از علائم و کتاب‌های تجاری ساخته و بعداً با چارچوب‌های CSS وارد وب شد، مانند بوت استرپ ( Bootstrap) معروف توییتر، که مجموعه ای از عناصر UI مانند تایپوگرافی، دکمه ها و لیست های کشویی را ارائه می‌داد.
متد طراحی اتمی (Atomic Design) باعث محکم‌تر شدن آن‌ها شد و با Google Material Design استاندارد‌ها و دستورالعمل‌هایی را تصویب کردند.

امروزه تعداد زیادی از شرکت‌ها در حال ساخت سیستم‌های طراحی اختصاصی خود هستند تا با رشد محصولات خود همچنان از ثبات و سازگاری برخوردار باشند و در عین‌حال مقیاس‌گذاری را نیز برای آنها آسان‌تر کند. HubSpot Canvas، زبان تصویری Airbnb ،Polaris از Shopify و Lightning از Salesforce چند نمونه عالی از این دیزاین سیستم‌هاست.

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

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

http://bit.ly/dxgn699

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

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

#دیزاین #دیزاین_سیستم
@Dexign فلسفه دیزاین

______

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

خوشحال می‌شیم در این گفتگو همراه ما باشین.

آدرس روم:‌ https://www.clubhouse.com/join/peachak-co/tE7ztfzO/mWLnQqVa

آدرس کلاب‌هاوس: https://www.clubhouse.com/@mehrandvd

کانال فلسفه نرم‌افزار @SoftwarePhilosophy
.