Software Philosophy
3.45K subscribers
160 photos
41 videos
1.54K links
چکیده‌ای از مفاهیم به روز مهندسی نرم افزار برای مهندسین نرم‌افزار.
معماری نوین نرم‌افزار، تکنولوژی‌های برنامه نویسی جدید
Download Telegram
#پست_مجدد این پست تا به حال نزدیک به ۱۲۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
نیازمندی‌های نرم‌افزاری در سال‌های اخیر نسبت به گذشته تغییرات زیادی داشته‌اند .
تا چند سال پیش یک برنامه بزرگ ده‌ها سرور داشت، ثانیه ملاک پاسخگویی و گیگابایت ملاک داده‌ها بود، اما امروزه کاربران از زمان پاسخگویی سیستم‌ها، واکنشی در حد میلی‌ثانیه انتظار دارند و داده‌های بزرگ در Petabytes اندازه‌گیری می‌شوند .
بنابراین ما نیازمند سیستم‌هایی هستیم که با انعطاف پذیری بالا توانمندی پاسخگویی به حجم اطلاعات بسیار زیاد در زمان مناسب را داشته باشند.
طراحی واکنش‌گرا یا Reactive پاسخی بود به این نیازمندی که تاثیر عمده‌ای بر روند تولید سیستم‌ها گذاشته است‌.

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

https://www.reactivemanifesto.org

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

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

___
Forwarded from Moien Tajik 💭
یه بنده خدایی با قابلیت جدید Client to Server Streaming تو SignalR اومده یه سرویس درست کرده و روی Raspberry Pi و Linux اجراش کرده.✌🏻

یکی از سرویس های Azure ، سرویس Azure Cognitive Service هست که Face Detection داره و Emotion هایی مثل خنده ، گریه ، ترس و عصبانی بودن رو تشخیص میده. 🤬

این یه دوربین گذاشته و هر چند ثانیه یه عکس از بچه اش میگیره و میفرسته به این سرویس و این سرویس هم تشخیص میده که بچه گریه میکنه یا نه. 👶🏻

اگر درصد تشخیص Congnitive Service از گریه بچه بیشتر از 50% شد ، تو کروم به طرف یه Notification میده که Baby is crying و طرف میتونه اونموقع Video Stream رو ، رو دوربین Start کنه و در لحظه بچه رو ببینه. 🎥

[ لینک دمو ویدیویی ] : youtu.be/mg-B13bGNeI

[ لینک مقاله ] : kutt.it/sigcog

〰️〰️〰️〰️〰️〰️
#SignalR #Streaming #Azure #RaspberryPi
با ایجاد هر تکنولوژی در دنیای نرم افزار ، انبوهی از قابلیت‌های جدید ایجاد می‌شود که به توسعه دهندگان این امکان را می‌دهند تا برنامه‌هایی با قابلیت‌های بالا و کد کمتر ایجاد کنند . در لینک زیر 20 کتابخانه مبتنی بر .netcore معرفی شده است که هر برنامه نویسی ممکن است به آنها نیاز داشته باشد.

https://codinginfinite.com/best-top-dot-net-core-useful-libraries-open-source/

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

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

___
Forwarded from فلسفه دیزاین
دیزاین به احترام حریم خصوصی

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

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

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

سوال اینجاست که چرا «قوانین و مقررات» یک سرویس — که معمولا خیلی مهم هستند — را نخوانده رها می‌کنیم؟ پاسخ به این سوال ساده است.

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

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

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

https://bit.ly/dxgn467

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

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

#مفاهیم #طراحی #حریم_خصوصی
@Dexign فلسفه دیزاین

___
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
❇️ نحوه ساخت اپلیکیشنهای Real-time تحت وب با ASP NET Core SignalR (زبان اصلی زیر نویس دار)

[02:10] - Quick introduction to SignalR
[06:06] - Targeting clients
[10:51] - Leveraging the Hub protocol
[12:18] - SignalR Transports
[13:55] - Hosting SignalR in a background service
[16:22] - Azure SignalR Service
[18:22] - The SignalR Java client on Android
[22:34] - Streaming with SignalR

https://channel9.msdn.com/Shows/On-NET/Real-time-web-applications-with-ASPNET-Core-SignalR
_______________
@IranAspMvc
Forwarded from Iran Agile
🔴 اگر بر روی سیستمی کار می کنید که از نظر زیرساخت فنی با اصول چابکی همخوان نیست، معماری یا مدل طراحی یا نحوه پابلیش سیستم را دوست ندارید و بدنبال تغییر آن هستید. از طرفی دیگر اصطلاحا در وضعیت براوون فیلد هستید و مشتریانی دارید که از سیستم استفاده می کنند، معمولا تغییرات بنیادی فنی و معماری خیلی سخت هستند.
برخی اوقات میخواهیم سیستم موجود را به سمت معماری سرویس گرا ببریم یا کل سیستم را زیر پوشش تست خودکار بیاوریم یا ... معمولا هیچ وقت فرصت نمی شود.

داشتن یک نقشه راه برای ایجاد چنین تغییراتی میتواند برای شما مفید باشد. این نقشه راه باید معلوم کند که شما در کوتاه مدت و بلند مدت میخواهید چه تغییراتی ایجاد کنید. در زیر یک نمونه از این نقشه راه را میتوانید مشاهده کنید:

اهداف در کوتاه مدت:

Automate build process & set up CI pipeline.
Agree with stakeholders to accept current "status quo" as baseline quality for CI/CD.
Every new line of code gets a unit test.
Build metric hooks and set up a measurement system.
Build service API for core monolith.

اهداف میان مدت

Introduce Coding Conventions and add measurement to CI pipeline
Stop the current branching process and move towards genuine CD process
Automated deployment to Test Stage
Automate e2e tests for critical user journeys
Decouple frontend and backend.

اهداف بلند مدت

Build new capabilities as autonomous services.
Containerize services.
Extract service components from existing monolith.
Move towards polyglot development.
Move individual services to Cloud.
Build Security Services (IAM, Secrets-as-Service, etc.)

بیشتر مطالعه کنید:
https://bit.ly/2H1z7IE

@iranagile
#پست_مجدد این پست تا به حال نزدیک به ۱۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
این همه انواع Messaging Service روی Azure؟ چه خبره؟

اگر از سرویس Cloud مایکروسافت یا همان Microsoft Azure برای طراحی و معماری Solution های خود استفاده می‌کنید، روزی خواهد رسید که به یک Service Bus نیاز خواهید داشت. سرویس باس، سرویسی است که در معماری به شما کمک می‌کند برنامه‌های مختلف سیستم که نیاز دارند با هم ارتباط داشته باشند را به هم متصل کنید. معمولا اگر این اتصال از طریق database polling صورت پذیرد در مقیاس بالا بسیار هزینه‌بر و پیچیده می‌شود. به همین دلیل استفاده از «باس» بسیار پر کاربرد است.
در Azure سه نوع سرویس به این منظور تعبیه شده که هر کدام کاربردهای تخصصی خود را دارند:
- Event Grid
- Event Hub
- Service Bus

برای درک تفاوت این سرویس‌ها ابتدا باید تفاوت مفهوم Event و Message را در Azure بدانید که در مقاله زیر توضیح داده شده‌است. اما کاربرد هر یک را می‌توان به این صورت خلاصه گفت:
- Event Grid:
انتشار رویدادها و Reactive Programming، مثلا عکس‌العمل نشان دادن به تغییر وضعیت‌ها در دیتا

- Event Hub:
کار با stream های سنگین دیتا. برای کار و مدیریت میلیون‌ها رویداد در ثانیه در Big data pipleline طراحی شده.

- Service Bus:
انتقال پیام (Message) بین سیستم‌های Enterprise.

مستند زیر این مفاهیم را با جزئیات کامل‌تری شرح می‌دهد.

https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services

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

https://ow.ly/fhwz30nWt1e

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

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


___
Forwarded from فلسفه دیزاین
بررسی طیف رنگ در طراحی بصری

یکی از روندهای مهمی که از گذشته تا امروز در طراحی‌ها جایگاه خود را حفظ کرده، طیف‌های رنگ یا همان Gradientها است. استفاده از آن‌ها از سال ۲۰۱۸ با بروزرسانی Flat Design با قدرتی بیش از پیش ادامه پیدا کرده است؛ بطوریکه امروزه در بیشتر وب سایت‌ها دیده می‌شود.

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

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

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

مقاله امروز را از دست ندهید!

https://bit.ly/dxgn471

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

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

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

منابع بیشتر برای طیف‌های رنگی در طراحی بصری:
https://paletton.com
https://www.grabient.com
https://webgradients.com
https://webkul.github.io
https://codepen.io/supah/pen/prVVOx
شاید برای شما هم تا کنون پیش آمده باشد که در یک وب سایت با اشکال هندسی روبرو شوید که در #CSS تولید شده اند، یا حتی بخواهید در وب سایت خود این اشکال جالب را قرار دهید. یکی از شکل‌های پرتکرار در وب سایت‌ها، مثلث است که از آن در ایجاد انواع مختلف مثلث، جهت‌نما (فلش) و یا حتی جهت‌دار کردن اشکال دیگر استفاده می‌گردد.
لینک زیر به صورت بسیار مختصر و مفید، به همراه یک انیمیشن عالی، به توضیح نحوه ایجاد آن می پردازد:

https://bit.ly/1GzOIaN

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

https://bit.ly/2W9NzDf

#محمدرضا_حاج_بابایی (https://ow.ly/PnEY30oq1sK)

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


___
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
معرفی EFSecondLevelCache.Core
در سری #معرفی_اکستنشن_های_کاربردی_EFCore

توسط این کتابخانه میتونین کش سطح دوم (second level caching) رو روی EF Core فعال کنین. در واقع میتونین نتیجه کوئری هاتون رو کش کنین تا دفعه بعد، به جای دیتابیس، از کش خونده بشه.
این کتابخانه توسط وحید نصیری عزیز، مدیر سایت dotnettips.info نوشته شده است.

🔸این کتابخانه برای مدیریت Caching اش از کتابخانه CacheManager استفاده میکنه که فوق العاده قدرتمند و انعطاف پذیر هست و قبلا معرفیش کردیم.

🔹در حال حاضر این کتابخانه محبوبترین و سپس کتابخانه EntityFrameworkCore.Cacheable که قبلا معرفی کردیم جز بهترین کتابخانه های کش سطح دوم برای EF Core هستند.

🔸مزیت این کتابخانه نسبت به اون، اینه که از async هم پشتیبانی میکنه. مثال :
var products = context.Products.Include(x => x.Tags).Cacheable().FirstOrDefault();

🔹مزیت دیگه اش اینه که به صورت خودکار بحث اعتبار سنجی کش (اصطلاحا Invalidation یا Revalidation) رو به صورت خودکار مدیریت میکنه به این صورت که به محض تغییر یه entity یعنی (insert, update, delete)، آیتم های مربوط به اون رو از کش حذف میکنه تا توی کوئری بعدی بروز رسانی بشه.

https://github.com/VahidN/EFSecondLevelCache.Core/
_______________
@IranAspMvc
👍1
#پست_مجدد این پست تا به حال بیش از ۶۱۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

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

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

پست زیر این دو مفهوم را معرفی کرده و تفاوت آن‌ها را در مدیریت پروژه شرح داده‌است.

https://mehrandvd.me/2017/08/02/effort-vs-time-estimation/

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

https://ow.ly/958i30erVZs

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

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

___
Forwarded from فلسفه دیزاین
۶ مرحله‌ی ساخت تجربه کاربری

به طور ساده، UX یا User Experience به معنی احساساتی است که کاربر هنگام استفاده از یک محصول خاص دارد که شامل «احساس کلی نسبت به محصول»، «هیجانات» و «ارتباطات فیزیکی» با محصول، می‌شود.

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

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

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

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

https://bit.ly/dxgn475

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

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

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


ــــــــــ
ما همیشه به دنبال آپدیت کردن نسخه سیستم عامل‌هایمان هستیم. اما به عنوان developer آیا به دنبال آپدیت بودن نسخه فریمورکی که از آن استفاده می‌کنیم نیز هستیم؟
ما نباید از قافله عقب باشیم و اگر از فریمورکی استفاده می‌کنیم، می‌بایست همیشه به دنبال استفاده از آخرین نسخه و امکانات آن باشیم.
در استفاده از ری‌اکت ۱۶ به جای ری‌اکت ۱۵ مسایل زیادی وجود دارد که باید در نظر گرفته شوند.

این مقاله به شما کمک می‌کند با ری اکت ۱۵ خداحافظی کنید و به روز شوید!

https://medium.freecodecamp.org/why-react16-is-a-blessing-to-react-developers-31433bfc210a


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

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

___
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
رمزنگاری خودکار فیلدها در EF Core
بعلاوه بررسی قابلیت HasConversion و ValueConverter در EF Core

🔸مقاله زیر قابلیت جالبی (و البته خاصی) رو به نام ValueConverter ها در EF Core 2.1 (به بالا) معرفی میکنه، توسط این قابلیت دیتا های شما قبل از اینکه وارد دیتابیس بشه (مثلا Add و Update و...) این امکان رو به شما میده که تغییرش بدین؛ مثلا مقادیر enum تون رو به جای اینکه عددش توی دیتابیس ذخیره بشه، متن string اش ذخیره بشه.
این کار پشت صحنه و به صورت خودکار انجام میشه و نیازی نیست توی کد هاتون خودتون هندل اش کنین.

🔹همچنین موقع واکشی کردن اطلاعات، قبل از اینکه دیتا به دست شما برسه این امکان رو به شما میده که تغییرش بدین، مثلا همون متن string رو به enum مربوطه تبدیل کنین. این کار هم به صورت خودکار انجام میشه و نیازی نیست توی کوئری هاتون کد اضافه تری بنویسین.

🔸حالا وحید نصیری عزیز با استفاده از این ترفند اومده یه مثال زده. اومده یه ValueConverter نوشته که کارش Encrypt کردن متون قبل از Insert شدن و Decrypt کردن اون به هنگام واکشی هست. در نتیجه متون شما توی دیتابیس رمزنگاری شده ذخیره میشه، ولی وقتی توی برنامه کوئری میزنین، متن عادی (رمزگشایی شده) رو مشاهده میکنین.

🔹البته این صرفا یک مثال (خلاقانه) هست و به نظرم راه بهینه ای واسه رمزنگاری اطلاعات دیتابیس نباشه، توی SQLServer راه های اصولی تری مخصوص این قضیه وجود داره

https://www.dotnettips.info/post/3015
_______________
@IranAspMvc
#پست_مجدد این پست تا به حال بیش از ۵۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
استفاده از امکانات Azure و TFS برای تیم‌های برنامه‌نویسی بسیار جذاب است. بسیاری از مشکلاتی که در تیم‌های نرم‌افزاری پیش می‌آید به علت نبود فرایند‌های درست و ابزارهای مناسب است. یکی از دغدغه‌های تیم‌های برنامه‌نویسی، نحوه تعامل و همکاری اعضای تیم در ساخت نیازمندی‌های نرم‌افزار به صورت با کیفیت است. نیازها باید طوری شفاف تعریف شوند که قابل تست باشند. اصولا اگر یک نیازمندی به اندازه‌ای واضح تعریف نشده که بتوان آن را تست کرد، احتمالا کد آن هم خیلی واضح به آن هدف نخواهد رسید!

در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویس‌های Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature‌ ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی می‌شوند. سپس این Feature ها به Backlog Item ها شکسته می‌شوند. یک Backlog Item در حقیقت یک نیازمندی‌است است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.

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

https://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/

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

https://ow.ly/3NGm30b5IjZ

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

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


___
Forwarded from فلسفه دیزاین
تقابل دو نظریه:
تفکر دیزاین؛ شکست یا موفقیت؟

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

https://bit.ly/dxgn476_1

حال که ویدئو را دیدید، می‌خواهیم از سوی دیگر به موضوع بنگریم و صحبت‌های خانم Lillian Ayla Ersoy را، کسی که در زمینه تفکر دیزاین کارگاه‌ها و نشست‌های بسیاری داشته است، بخوانیم. ایشان بحث را به این شکل مطرح می‌کنند که Design Thinking به عنوا یک روش‌شناسی مشکلی نداشته و نحوه‌‌ اجرای آنست که ممکن است منجر به شکست شود.

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

https://bit.ly/dxgn476_2

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

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

#ویدئو #نظریه #تفکر_دیزاین
@Dexign فلسفه دیزاین


_______
گراف دیتابیس شامل مجموعه‌ای از جداول node و جداول edge است. node اشاره به یک موجودیت دارد و edge ارتباط بین node ها را بیان می‌کند .گراف دیتابیس‌ها زمانی استفاده می‌شوند که روابط پیچیده چند به چند بین اجزا وجود دارد. مثلا در یک شبکه اجتماعی افراد node هستند و ارتباط بین انها edge. ممکن است بین دو نفر چند نوع ارتباط وجود داشته باشد، پیاده سازی این الگو در دیتابیس‌های غیرگرافی، بسیار سخت است.

مبحث گراف دیتابیس مدتی است که به Microsoft sql server افزوده شده است، لینک زیر آخرین امکانات مبحث گراف‌ها را در sql server 2019 توضیح می‌دهد.

https://www.sqlshack.com/graph-database-features-in-sql-server-2019-part-1/

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

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

___