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
[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
Channel 9
Real-time web applications with ASP.NET Core SignalR
Brady Gaster (@bradygaster) joins Cecil (@cecilphillip) to show how easy it is to add real-time functionality to your web applications using ASP.NET Core SignalR. They discuss topics such as targeting
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.)
بیشتر مطالعه کنید:
http://bit.ly/2H1z7IE
@iranagile
برخی اوقات میخواهیم سیستم موجود را به سمت معماری سرویس گرا ببریم یا کل سیستم را زیر پوشش تست خودکار بیاوریم یا ... معمولا هیچ وقت فرصت نمی شود.
داشتن یک نقشه راه برای ایجاد چنین تغییراتی میتواند برای شما مفید باشد. این نقشه راه باید معلوم کند که شما در کوتاه مدت و بلند مدت میخواهید چه تغییراتی ایجاد کنید. در زیر یک نمونه از این نقشه راه را میتوانید مشاهده کنید:
✅ اهداف در کوتاه مدت:
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.)
بیشتر مطالعه کنید:
http://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
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/fhwz30nWt1e
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
اگر از سرویس 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
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/fhwz30nWt1e
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Docs
Compare Azure messaging services - Azure Service Bus
Describes the three Azure messaging services - Azure Event Grid, Event Hubs, and Service Bus. Recommends which service to use for different scenarios.
Forwarded from فلسفه دیزاین
بررسی طیف رنگ در طراحی بصری
یکی از روندهای مهمی که از گذشته تا امروز در طراحیها جایگاه خود را حفظ کرده، طیفهای رنگ یا همان Gradientها است. استفاده از آنها از سال ۲۰۱۸ با بروزرسانی Flat Design با قدرتی بیش از پیش ادامه پیدا کرده است؛ بطوریکه امروزه در بیشتر وب سایتها دیده میشود.
اگر بخواهیم به نمونههای موفق استفاده از طیفهای رنگی گریزی بزنیم، بعید است نام Spotify را نیاوریم. این اپلیکیشن را میتوان به عنوان یک نمونه موفق در استفاده چشمنواز از طیف رنگی مثال زد. طراحان Spotify با ترکیب رنگهای مختلف طرحیهای هیجانانگیز و جذابی را برای کاربرای خود ایجاد کردهاند.
با وجود نمونههای موفق استفاده از طیفهای رنگی، این تکنیک، همیشه هم اثر مثبتی روی طراحیها نداشته، بلکه گاهی باعث حس پیچیدگی و سردرگمی در کاربران (بواسطه وجود رنگهای متنوع و مختلف) میشود.
حال این سوال مطرح است که، چاره چیست؟ برای استفاده صحیح از طیفهای رنگی در طرحهای خود، گذشته از انتخاب رنگهای درست، بایستی از نحوه استفاده صحیح طیفها نیز آگاهی داشته باشیم.
در ادامه شما را به خواندن مقاله جذاب امروز دعوت میکنم که در آن، نویسنده نکات مهم ساخت و استفاده از طیفهای رنگی را، به خوبی توضیح داده است.
مقاله امروز را از دست ندهید!
http://bit.ly/dxgn471
(زمان حدودی مطالعه، ۵ دقیقه)
نویسنده: نیما حکیمرابط
#طیف_رنگی #رنگ #طراحی_بصری
@Dexign فلسفه دیزاین
منابع بیشتر برای طیفهای رنگی در طراحی بصری:
http://paletton.com
https://www.grabient.com
https://webgradients.com
https://webkul.github.io
https://codepen.io/supah/pen/prVVOx
یکی از روندهای مهمی که از گذشته تا امروز در طراحیها جایگاه خود را حفظ کرده، طیفهای رنگ یا همان Gradientها است. استفاده از آنها از سال ۲۰۱۸ با بروزرسانی Flat Design با قدرتی بیش از پیش ادامه پیدا کرده است؛ بطوریکه امروزه در بیشتر وب سایتها دیده میشود.
اگر بخواهیم به نمونههای موفق استفاده از طیفهای رنگی گریزی بزنیم، بعید است نام Spotify را نیاوریم. این اپلیکیشن را میتوان به عنوان یک نمونه موفق در استفاده چشمنواز از طیف رنگی مثال زد. طراحان Spotify با ترکیب رنگهای مختلف طرحیهای هیجانانگیز و جذابی را برای کاربرای خود ایجاد کردهاند.
با وجود نمونههای موفق استفاده از طیفهای رنگی، این تکنیک، همیشه هم اثر مثبتی روی طراحیها نداشته، بلکه گاهی باعث حس پیچیدگی و سردرگمی در کاربران (بواسطه وجود رنگهای متنوع و مختلف) میشود.
حال این سوال مطرح است که، چاره چیست؟ برای استفاده صحیح از طیفهای رنگی در طرحهای خود، گذشته از انتخاب رنگهای درست، بایستی از نحوه استفاده صحیح طیفها نیز آگاهی داشته باشیم.
در ادامه شما را به خواندن مقاله جذاب امروز دعوت میکنم که در آن، نویسنده نکات مهم ساخت و استفاده از طیفهای رنگی را، به خوبی توضیح داده است.
مقاله امروز را از دست ندهید!
http://bit.ly/dxgn471
(زمان حدودی مطالعه، ۵ دقیقه)
نویسنده: نیما حکیمرابط
#طیف_رنگی #رنگ #طراحی_بصری
@Dexign فلسفه دیزاین
منابع بیشتر برای طیفهای رنگی در طراحی بصری:
http://paletton.com
https://www.grabient.com
https://webgradients.com
https://webkul.github.io
https://codepen.io/supah/pen/prVVOx
Medium
Gradients in UI Design
For a long time, using gradients was the biggest no-no in design. Designers tended to avoid gradients because they created a strong…
شاید برای شما هم تا کنون پیش آمده باشد که در یک وب سایت با اشکال هندسی روبرو شوید که در #CSS تولید شده اند، یا حتی بخواهید در وب سایت خود این اشکال جالب را قرار دهید. یکی از شکلهای پرتکرار در وب سایتها، مثلث است که از آن در ایجاد انواع مختلف مثلث، جهتنما (فلش) و یا حتی جهتدار کردن اشکال دیگر استفاده میگردد.
لینک زیر به صورت بسیار مختصر و مفید، به همراه یک انیمیشن عالی، به توضیح نحوه ایجاد آن می پردازد:
https://bit.ly/1GzOIaN
همچینن در زیر، لینک یک تولید کننده مثلث در کد #CSS آورده شده است که بعد از مطالعه لینک بالا می توانید به راحتی از آن در طراحی های خود استفاده نمایید.
https://bit.ly/2W9NzDf
#محمدرضا_حاج_بابایی (http://ow.ly/PnEY30oq1sK)
کانال تلگرام:
@SoftwarePhilosophy
___
لینک زیر به صورت بسیار مختصر و مفید، به همراه یک انیمیشن عالی، به توضیح نحوه ایجاد آن می پردازد:
https://bit.ly/1GzOIaN
همچینن در زیر، لینک یک تولید کننده مثلث در کد #CSS آورده شده است که بعد از مطالعه لینک بالا می توانید به راحتی از آن در طراحی های خود استفاده نمایید.
https://bit.ly/2W9NzDf
#محمدرضا_حاج_بابایی (http://ow.ly/PnEY30oq1sK)
کانال تلگرام:
@SoftwarePhilosophy
___
CSS-Tricks
CSS Triangle
HTML You can make them with a single div. It's nice to have classes for each direction possibility. CSS The idea is a box with zero width and height. The
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
✅معرفی EFSecondLevelCache.Core
در سری #معرفی_اکستنشن_های_کاربردی_EFCore
توسط این کتابخانه میتونین کش سطح دوم (second level caching) رو روی EF Core فعال کنین. در واقع میتونین نتیجه کوئری هاتون رو کش کنین تا دفعه بعد، به جای دیتابیس، از کش خونده بشه.
این کتابخانه توسط وحید نصیری عزیز، مدیر سایت dotnettips.info نوشته شده است.
🔸این کتابخانه برای مدیریت Caching اش از کتابخانه CacheManager استفاده میکنه که فوق العاده قدرتمند و انعطاف پذیر هست و قبلا معرفیش کردیم.
🔹در حال حاضر این کتابخانه محبوبترین و سپس کتابخانه EntityFrameworkCore.Cacheable که قبلا معرفی کردیم جز بهترین کتابخانه های کش سطح دوم برای EF Core هستند.
🔸مزیت این کتابخانه نسبت به اون، اینه که از async هم پشتیبانی میکنه. مثال :
https://github.com/VahidN/EFSecondLevelCache.Core/
_______________
@IranAspMvc
در سری #معرفی_اکستنشن_های_کاربردی_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
GitHub
GitHub - VahidN/EFSecondLevelCache.Core: Entity Framework Core Second Level Caching Library
Entity Framework Core Second Level Caching Library - VahidN/EFSecondLevelCache.Core
👍1
#پست_مجدد این پست تا به حال بیش از ۶۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
شایعترین دلیل تخمین زمان اشتباه یک پروژه
تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایعترین عواملی که باعث میشود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت میکنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جملهای مانند «این کار تا پنجشنبه هفته بعد انجام میشود» جملهای است که زمان انجام شدن کار را تخمین میزند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامهنویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح میدهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام میشود و صرفا حجم کار مورد نیاز بیان شده.
برای یک تخمین موفق باید این مفاهیم در جلسات کاملا واضح شوند و در مورد آنها جداگانه صحبت شود. همچنین بهتر است از هر دو طیف افراد بالا در جلسات حضور داشته باشند تا جوانب مختلف بررسی شود.
پست زیر این دو مفهوم را معرفی کرده و تفاوت آنها را در مدیریت پروژه شرح دادهاست.
http://mehrandvd.me/2017/08/02/effort-vs-time-estimation/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/958i30erVZs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایعترین عواملی که باعث میشود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت میکنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جملهای مانند «این کار تا پنجشنبه هفته بعد انجام میشود» جملهای است که زمان انجام شدن کار را تخمین میزند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامهنویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح میدهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام میشود و صرفا حجم کار مورد نیاز بیان شده.
برای یک تخمین موفق باید این مفاهیم در جلسات کاملا واضح شوند و در مورد آنها جداگانه صحبت شود. همچنین بهتر است از هر دو طیف افراد بالا در جلسات حضور داشته باشند تا جوانب مختلف بررسی شود.
پست زیر این دو مفهوم را معرفی کرده و تفاوت آنها را در مدیریت پروژه شرح دادهاست.
http://mehrandvd.me/2017/08/02/effort-vs-time-estimation/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/958i30erVZs
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Effort vs. Time Estimation - Dot Philosophy
Estimating the required time for a task, is not an easy job to do, if you want to be precise! The main problem with estimating is that, most of the time it is wrong! Being wrong is not too bad for an estimation. But, being too wrong is a disaster for a project.…
Forwarded from فلسفه دیزاین
۶ مرحلهی ساخت تجربه کاربری
به طور ساده، UX یا User Experience به معنی احساساتی است که کاربر هنگام استفاده از یک محصول خاص دارد که شامل «احساس کلی نسبت به محصول»، «هیجانات» و «ارتباطات فیزیکی» با محصول، میشود.
اصطلاح UX یا «تجربه کاربری» اولین بار توسط Donald Norman، معاون اسبق تکنوتوژیهای پیشرفته شرکت اپل بوجود آمد. او عقیده داشت مفاهیم «رابط کاربری» و «کاربردپذیری» بسیار به هم نزدیک هستند هروقت به طراحی یک محصول فکر میکنیم، باید به تمام تجربیات یک کاربر و رابطهاش با محصول بنگریم.
این طرز تفکر میتواند یک محصول را از دید «طراحی صنعتی»، «هویت بصری»، «رابط کاربری» و «ارتباطات فیزیکی و تجربه لمس محصول» و حتی « طراحی راهنمای استفاده» مورد بررسی و قرار داده و در نهایت آن را بهروز کند.
چرا «تجربه کاربری» انقدر مهم است؟ یک تجربه کاربری خوب، با ایجاد احساس مثبت در کاربران نسبت به محصول، میتواند میزان رضایت و از همه مهمتر وفاداری کاربران را افزایش دهد.
طراحی و نگرش تجربه کاربری یک محصول نسبت به محصول دیگر میتواند کاملا متفاوت باشد، پس بهتر است هدفمان لزوما شبیه شدن به شرکتهای بزرگ در این حوزه نباشد و باید تلاش کنیم وقت، انرژی و منابعمان را صرف یکی از بزرگترین اهداف هر محصول، یعنی جذب کاربران بیشتر و تبدیل کردن یک کاربر عادی به کاربر وفادار بکنیم.
مقالهای که میخوانید، به شرح دقیق طراحی تجربه کاربری در ۶ مرحله میپردازد.
بدیهیست که موثرترین روش در طراحی تجربه کاربری، طراحی روش منحصر بفرد خود شماست. روشی که واقعا کار میکند و به معنای واقعی به درد خود شما میخورد.
http://bit.ly/dxgn475
(زمان حدودی مطالعه، ۱۲ دقیقه)
نویسنده: آرش اصغری
#تجربه_کاربری #روش #طراحی_محصول
@Dexign فلسفه دیزاین
ــــــــــ
به طور ساده، UX یا User Experience به معنی احساساتی است که کاربر هنگام استفاده از یک محصول خاص دارد که شامل «احساس کلی نسبت به محصول»، «هیجانات» و «ارتباطات فیزیکی» با محصول، میشود.
اصطلاح UX یا «تجربه کاربری» اولین بار توسط Donald Norman، معاون اسبق تکنوتوژیهای پیشرفته شرکت اپل بوجود آمد. او عقیده داشت مفاهیم «رابط کاربری» و «کاربردپذیری» بسیار به هم نزدیک هستند هروقت به طراحی یک محصول فکر میکنیم، باید به تمام تجربیات یک کاربر و رابطهاش با محصول بنگریم.
این طرز تفکر میتواند یک محصول را از دید «طراحی صنعتی»، «هویت بصری»، «رابط کاربری» و «ارتباطات فیزیکی و تجربه لمس محصول» و حتی « طراحی راهنمای استفاده» مورد بررسی و قرار داده و در نهایت آن را بهروز کند.
چرا «تجربه کاربری» انقدر مهم است؟ یک تجربه کاربری خوب، با ایجاد احساس مثبت در کاربران نسبت به محصول، میتواند میزان رضایت و از همه مهمتر وفاداری کاربران را افزایش دهد.
طراحی و نگرش تجربه کاربری یک محصول نسبت به محصول دیگر میتواند کاملا متفاوت باشد، پس بهتر است هدفمان لزوما شبیه شدن به شرکتهای بزرگ در این حوزه نباشد و باید تلاش کنیم وقت، انرژی و منابعمان را صرف یکی از بزرگترین اهداف هر محصول، یعنی جذب کاربران بیشتر و تبدیل کردن یک کاربر عادی به کاربر وفادار بکنیم.
مقالهای که میخوانید، به شرح دقیق طراحی تجربه کاربری در ۶ مرحله میپردازد.
بدیهیست که موثرترین روش در طراحی تجربه کاربری، طراحی روش منحصر بفرد خود شماست. روشی که واقعا کار میکند و به معنای واقعی به درد خود شما میخورد.
http://bit.ly/dxgn475
(زمان حدودی مطالعه، ۱۲ دقیقه)
نویسنده: آرش اصغری
#تجربه_کاربری #روش #طراحی_محصول
@Dexign فلسفه دیزاین
ــــــــــ
Invisionapp
The UX design process in 6 stages | Inside Design Blog
A crash course for UX newbies to setting up your own UX process.
ما همیشه به دنبال آپدیت کردن نسخه سیستم عاملهایمان هستیم. اما به عنوان developer آیا به دنبال آپدیت بودن نسخه فریمورکی که از آن استفاده میکنیم نیز هستیم؟
ما نباید از قافله عقب باشیم و اگر از فریمورکی استفاده میکنیم، میبایست همیشه به دنبال استفاده از آخرین نسخه و امکانات آن باشیم.
در استفاده از ریاکت ۱۶ به جای ریاکت ۱۵ مسایل زیادی وجود دارد که باید در نظر گرفته شوند.
این مقاله به شما کمک میکند با ری اکت ۱۵ خداحافظی کنید و به روز شوید!
https://medium.freecodecamp.org/why-react16-is-a-blessing-to-react-developers-31433bfc210a
#مریم_کمالی (http://ow.ly/9Wa430mFGeK)
کانال تلگرام:
@SoftwarePhilosophy
___
ما نباید از قافله عقب باشیم و اگر از فریمورکی استفاده میکنیم، میبایست همیشه به دنبال استفاده از آخرین نسخه و امکانات آن باشیم.
در استفاده از ریاکت ۱۶ به جای ریاکت ۱۵ مسایل زیادی وجود دارد که باید در نظر گرفته شوند.
این مقاله به شما کمک میکند با ری اکت ۱۵ خداحافظی کنید و به روز شوید!
https://medium.freecodecamp.org/why-react16-is-a-blessing-to-react-developers-31433bfc210a
#مریم_کمالی (http://ow.ly/9Wa430mFGeK)
کانال تلگرام:
@SoftwarePhilosophy
___
freeCodeCamp.org
Why React16 is a blessing to React developers
By Harsh Makadia Just like how people are excited about updating their mobile apps and OS, developers should also be excited to update their frameworks. The new version of the different frameworks come with new features and tricks out of the box. Bel...
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
بعلاوه بررسی قابلیت 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
.NET Tips
رمزنگاری خودکار فیلدها توسط Entity Framework Core
از EF Core 2.1 به بعد، قابلیت جدیدی تحت عنوان «تبدیلگرهای مقدار»، به آن اضافه شدهاست. برای مثال در EF Core، زمانیکه اطلاعات Enums، در بانک اطلاعاتی ذخیره میشوند، معادل عددی آنها درج خواهند شد. اگر علاقمند باشید تا بجای این مقادیر عددی دقیقا همان رشتهی…
#پست_مجدد این پست تا به حال بیش از ۵۴۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
استفاده از امکانات Azure و TFS برای تیمهای برنامهنویسی بسیار جذاب است. بسیاری از مشکلاتی که در تیمهای نرمافزاری پیش میآید به علت نبود فرایندهای درست و ابزارهای مناسب است. یکی از دغدغههای تیمهای برنامهنویسی، نحوه تعامل و همکاری اعضای تیم در ساخت نیازمندیهای نرمافزار به صورت با کیفیت است. نیازها باید طوری شفاف تعریف شوند که قابل تست باشند. اصولا اگر یک نیازمندی به اندازهای واضح تعریف نشده که بتوان آن را تست کرد، احتمالا کد آن هم خیلی واضح به آن هدف نخواهد رسید!
در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی میشوند. سپس این Feature ها به Backlog Item ها شکسته میشوند. یک Backlog Item در حقیقت یک نیازمندیاست است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.
در مقاله زیر به طور خلاصه توضیح داده شدهاست که چگونه Sprint ها انجام میشوند.
http://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3NGm30b5IjZ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
در مقاله زیر تجربه استفاده از دو ابزار Team Foundation Server و یکپارچگی آن با سرویسهای Azure در یک پروژه عملی شرح داده شده است. در این فرایند Feature ها به عنوان زبان مشترک بین تیم فنی و بیزنس طراحی میشوند. سپس این Feature ها به Backlog Item ها شکسته میشوند. یک Backlog Item در حقیقت یک نیازمندیاست است که آنقدری کوچک شده که بتوان آن را به تنهایی تست کرد. به طوری که اگر تست تمام Backlog Item های یک Feature پاس شود، به معنی قابل تحویل بودن آن به تیم بیزنس باشد. سپس Task ها مجموعه کارهایی (فنی و غیر فنی) است که باید انجام شود تا بتوان تست یک Backlog Item را پاس کرد.
در مقاله زیر به طور خلاصه توضیح داده شدهاست که چگونه Sprint ها انجام میشوند.
http://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
http://ow.ly/3NGm30b5IjZ
#مهران_داودی (http://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
My Azure Experience: Handling the Requirements - Dot Philosophy
It is been a while I am doing some projects totally based on Azure ecosystem. As we are not working in a same place, it is a completely new experience for me because everything is different with working together in a company like place. I've recently started…
Forwarded from فلسفه دیزاین
تقابل دو نظریه:
تفکر دیزاین؛ شکست یا موفقیت؟
بارها و بارها در این کانال درباره تفکر دیزاین صحبت شده است. همیشه هم از نحوه اجرای آن و خوبیهای آن صحبت کردهایم. از ویژگیهای خوب یک دیزاینر این است که بتواند خوب گوش کند، نظرات متفاوت و متضاد را بشنود و به تحلیل بپردازد.
امروز میخواهیم به صحبتهای خانم Natasha Jen گریزی بزنیم. ایشان در ویدئو زیر با تمام قوا و با لحنی تند به «تفکر دیزاین» انتقاد میکند. سخن کوتاه میکنم و پیش از ادامه ماجرا شما را به دیدن ویدئوی زیر دعوت میکنم.
http://bit.ly/dxgn476_1
حال که ویدئو را دیدید، میخواهیم از سوی دیگر به موضوع بنگریم و صحبتهای خانم Lillian Ayla Ersoy را، کسی که در زمینه تفکر دیزاین کارگاهها و نشستهای بسیاری داشته است، بخوانیم. ایشان بحث را به این شکل مطرح میکنند که Design Thinking به عنوا یک روششناسی مشکلی نداشته و نحوه اجرای آنست که ممکن است منجر به شکست شود.
میتوان تقابل دو دیدگاه در برخورد با مقولهی دیزاین به عنوان یک سیستم فکری را به وضوح مشاهده کرد. پس از بررسی این دیدگاهها به نظر شما آیا برای ایجاد خلاقیت و نتیجهی بهتر، اصولن نیاز به پیروی از روشهای مشخص هست یا خیر؟ روشها و استانداردها با چه هدفی ساخته میشوند و آیا همیشه میتوانند مفید باشند؟
ویدئو و مقاله امروز را از دست ندهید:
http://bit.ly/dxgn476_2
(زمان حدودی مطالعه، ۸ دقیقه)
نویسنده: حسین میرزاده
#ویدئو #نظریه #تفکر_دیزاین
@Dexign فلسفه دیزاین
_______
تفکر دیزاین؛ شکست یا موفقیت؟
بارها و بارها در این کانال درباره تفکر دیزاین صحبت شده است. همیشه هم از نحوه اجرای آن و خوبیهای آن صحبت کردهایم. از ویژگیهای خوب یک دیزاینر این است که بتواند خوب گوش کند، نظرات متفاوت و متضاد را بشنود و به تحلیل بپردازد.
امروز میخواهیم به صحبتهای خانم Natasha Jen گریزی بزنیم. ایشان در ویدئو زیر با تمام قوا و با لحنی تند به «تفکر دیزاین» انتقاد میکند. سخن کوتاه میکنم و پیش از ادامه ماجرا شما را به دیدن ویدئوی زیر دعوت میکنم.
http://bit.ly/dxgn476_1
حال که ویدئو را دیدید، میخواهیم از سوی دیگر به موضوع بنگریم و صحبتهای خانم Lillian Ayla Ersoy را، کسی که در زمینه تفکر دیزاین کارگاهها و نشستهای بسیاری داشته است، بخوانیم. ایشان بحث را به این شکل مطرح میکنند که Design Thinking به عنوا یک روششناسی مشکلی نداشته و نحوه اجرای آنست که ممکن است منجر به شکست شود.
میتوان تقابل دو دیدگاه در برخورد با مقولهی دیزاین به عنوان یک سیستم فکری را به وضوح مشاهده کرد. پس از بررسی این دیدگاهها به نظر شما آیا برای ایجاد خلاقیت و نتیجهی بهتر، اصولن نیاز به پیروی از روشهای مشخص هست یا خیر؟ روشها و استانداردها با چه هدفی ساخته میشوند و آیا همیشه میتوانند مفید باشند؟
ویدئو و مقاله امروز را از دست ندهید:
http://bit.ly/dxgn476_2
(زمان حدودی مطالعه، ۸ دقیقه)
نویسنده: حسین میرزاده
#ویدئو #نظریه #تفکر_دیزاین
@Dexign فلسفه دیزاین
_______
Vimeo
Natasha Jen: Design Thinking is Bullsh*t
If Google Image search is your sole barometer, “design thinking uses just one tool: 3M Post-Its,” says Pentagram partner Natasha Jen. “Why did…
گراف دیتابیس شامل مجموعهای از جداول 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/
#شهریار_انتظام (http://ow.ly/qDN430nPiCg)
کانال تلگرام:
@SoftwarePhilosophy
___
مبحث گراف دیتابیس مدتی است که به Microsoft sql server افزوده شده است، لینک زیر آخرین امکانات مبحث گرافها را در sql server 2019 توضیح میدهد.
https://www.sqlshack.com/graph-database-features-in-sql-server-2019-part-1/
#شهریار_انتظام (http://ow.ly/qDN430nPiCg)
کانال تلگرام:
@SoftwarePhilosophy
___
SQL Shack - articles about database auditing, server performance, data recovery, and more
Graph Database features in SQL Server 2019 - Part 1
SQL Server 2019 contains enhancements for the Graph database: Edge Constraints, Match support in MERGE statement and Use a derived table or view aliases in graph match query
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
🔰 چند نکته از NET Core SDK و Visual Studio
🔸 برای استفاده از ورژن های پیش نمایش (preview) دات نت کور در Visual Studio 2019 باید گزینه "Use Previews of the .NET Core SDK" را از مسیر زیر فعال کنید
🔹 ورژن های زیر از NET Core SDK بر روی Visual Studio 2017 کار نمی کند زیرا به MSBuild ورژن 16 نیاز دارد که با VS 2017 سازگاری ندارد و با Visual Studio 2019 اوکی هست
- ورژن های 2.2.2xx مانند 2.2.203
- ورژن های 2.1.6xx مانند 2.1.603
- ورژن های 3.0.1xx مانند 3.0.100
🔸 برای استفاده از آخرین آپدیت NET Core SDK 2.2 قابل نصب بر روی Viusal Studio 2017 باید حتما از ورژن 2.2.106 استفاده کنید
🔹 برای استفاده از آخرین آپدیت NET Core SDK 2.1 قابل نصب بر روی Viusal Studio 2017 باید حتما از ورژن 2.1.506 استفاده کنید
🔸 اگر با Visual Studio Code و یا JetBrains Rider کار کنید، هیچگاه متوجه وجود مسائل بالا نخواهید شد!
دلیلش اینه که هر نسخه از ویژوال استادیو ورژن MSBuild خودش رو داره و وقتی ما دکمه F5 رو میزنیم پروژه ها رو با اون build میکنه، در صوتی که اگر با دستور dotnet build توی command line بیلد میکرد هیچ مشکلی نداشت
از طرفی هر نسخه SDK یه range از عدد ورژن های MSBuild ایی که پشتیبانی میکنه رو تو خودش داره، ویژوال استادیو هم چک میکنه ببینه اون ورژن MSBuild لازم رو داره یا نه که اگه نه خطا میده
اما IDE های دیگه مثل VS Code و Rider از خودشون MSBuild ندارن و F5 رو میزنیم، پروژه رو با دستور dotnet build توی cmd بیلد میکنه، پس مشکلی نخواهند داشت
اطلاعات بیشتر:
https://github.com/dotnet/announcements/issues/108
_______________
@IranAspMvc
🔸 برای استفاده از ورژن های پیش نمایش (preview) دات نت کور در Visual Studio 2019 باید گزینه "Use Previews of the .NET Core SDK" را از مسیر زیر فعال کنید
Tools -> Options -> Projects and Solutions -> .NET Core -> Use Previews of the .NET Core SDK.تنظیم بالا در ورژن های بعدی VS 2019 به مسیر زیر انتقال می یابد
Tools -> Options -> Environment -> Preview Features🔹 اگر از ورژن های NET Core 3 SDK استفاده کنید نسخه زبان سی شارپ مورد استفاده در پروژه به صورت پیشفرض 8 خواهد بود
🔹 ورژن های زیر از NET Core SDK بر روی Visual Studio 2017 کار نمی کند زیرا به MSBuild ورژن 16 نیاز دارد که با VS 2017 سازگاری ندارد و با Visual Studio 2019 اوکی هست
- ورژن های 2.2.2xx مانند 2.2.203
- ورژن های 2.1.6xx مانند 2.1.603
- ورژن های 3.0.1xx مانند 3.0.100
🔸 برای استفاده از آخرین آپدیت NET Core SDK 2.2 قابل نصب بر روی Viusal Studio 2017 باید حتما از ورژن 2.2.106 استفاده کنید
🔹 برای استفاده از آخرین آپدیت NET Core SDK 2.1 قابل نصب بر روی Viusal Studio 2017 باید حتما از ورژن 2.1.506 استفاده کنید
🔸 اگر با Visual Studio Code و یا JetBrains Rider کار کنید، هیچگاه متوجه وجود مسائل بالا نخواهید شد!
دلیلش اینه که هر نسخه از ویژوال استادیو ورژن MSBuild خودش رو داره و وقتی ما دکمه F5 رو میزنیم پروژه ها رو با اون build میکنه، در صوتی که اگر با دستور dotnet build توی command line بیلد میکرد هیچ مشکلی نداشت
از طرفی هر نسخه SDK یه range از عدد ورژن های MSBuild ایی که پشتیبانی میکنه رو تو خودش داره، ویژوال استادیو هم چک میکنه ببینه اون ورژن MSBuild لازم رو داره یا نه که اگه نه خطا میده
اما IDE های دیگه مثل VS Code و Rider از خودشون MSBuild ندارن و F5 رو میزنیم، پروژه رو با دستور dotnet build توی cmd بیلد میکنه، پس مشکلی نخواهند داشت
اطلاعات بیشتر:
https://github.com/dotnet/announcements/issues/108
_______________
@IranAspMvc
GitHub
.NET Core SDK 2.2.2nn and 2.1.6nn do not work with Visual Studio 2017 · Issue #108 · dotnet/announcements
.NET Core SDK 2.2.2nn and 2.1.6nn do not work with Visual Studio 2017 .NET Core SDK 2.2.2nn and 2.1.6nn do not work with Visual Studio 2017. For example, 2.2.203 and 2.1.603 cause failures in Visua...
#پست_مجدد این پست تا به حال بیش از ۲۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد
Forwarded from Software Philosophy
استفاده از تاریخ و زمان در زبانهای برنامهنویسی همواره برای برنامه نویسان دردسر ساز بوده است. این مشکل به ویژه برای برنامه نویسان ایرانی مشهود است زیرا همیشه درگیر تبدیل تاریخهای میلادی و شمسی به یکدیگرند.
اما واقعا چرا مفهوم تاریخ در علم کامپیوتر و متعاقبا زبانهای برنامهنویسی دردسر سازند؟
در مورد یک عدد عبارت ۱۰۰ تا بعد از ۳۰۰ چند میشود معنی دقیقی دارد و جواب ۴۰۰ است. ولی در مورد تاریخ عبارت «یک ماه» بعد از ۱۶ شهریور چه روزی است جواب دقیقی ندارد. آیا منظور از یک ماه ۳۰ روز است یا ۳۱ روز؟ با هر کدام از این فرضیهها جواب ممکن است ۱۵ شهریور یا ۱۶ شهریور باشد.
مقاله زیر به صورت کاملتری پیچیدگیهایی را که تاریخ و زمان با خود به دنیای برنامهنویسی آوردهاند را توضیح دادهاست.
http://mehrandvd.me/2016/07/26/datetime-complexities-programming-languages/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
اما واقعا چرا مفهوم تاریخ در علم کامپیوتر و متعاقبا زبانهای برنامهنویسی دردسر سازند؟
در مورد یک عدد عبارت ۱۰۰ تا بعد از ۳۰۰ چند میشود معنی دقیقی دارد و جواب ۴۰۰ است. ولی در مورد تاریخ عبارت «یک ماه» بعد از ۱۶ شهریور چه روزی است جواب دقیقی ندارد. آیا منظور از یک ماه ۳۰ روز است یا ۳۱ روز؟ با هر کدام از این فرضیهها جواب ممکن است ۱۵ شهریور یا ۱۶ شهریور باشد.
مقاله زیر به صورت کاملتری پیچیدگیهایی را که تاریخ و زمان با خود به دنیای برنامهنویسی آوردهاند را توضیح دادهاست.
http://mehrandvd.me/2016/07/26/datetime-complexities-programming-languages/
#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Date Complexities in Programming Languages - Dot Philosophy
The problem with date concept! We, as humans, are good with dates and times. So, why computers are not! Why do they bother us (developers) on this!? As a matter of fact, the main problem is with different views of different cultures and countries to dates…
Forwarded from فلسفه دیزاین
چشمانداز آینده به سوی دیزاین مبتنی بر صدا
صدا همچنان یکی از مباحث پرطرفدار، همراه با رشد سریع است. پیش بینی شده که صنعت بلندگوهای هوشمند در سال ۲۰۱۹ دارای نرخ رشد ۶۳ درصدی نسبت به سال گذشته است. این پیشبینی، بلندگوهای هوشمند را سریع ترین دستگاه های ارتباطی در سال ۲۰۱۹ میدانند.
در حال حاضر مردم عمدتا از دستگاههای Alexa و Google Home خود فقط برای پخش موسیقی و بررسی آب وهوا استفاده میکنند. همراه با رشد بازار، نیاز است که دستگاههای اولیه از این پیشرفت تبعیت کنند و نقش مفیدتری در زندگی روزمره مردم ایفا نمایند.
در مسیر پیشرفت، بیشتر از همیشه صنعت نیاز به دیزاینرهایی دارد که بتواند برنامههای صوتی مفید و کاربرپسند ایجاد کنند. در این مسیر دیزاینرها میتواند تجربه مبتنی بر صدای خود را از متوسط به جادویی بیابند، گرچه با این چالش مواجهند که باید تمام زمینههای حریم خصوصی، امنیت و اخلاق را درنظربگیرند و رمز ادامه مسیر ایجاد تعادل بین امنیت و قابلیت استفاده است.
امروز شما را پای مقاله ای خواندنی درباره اینکه چگونه با اصلاحات ساده تبدیل به یک دیزاینر مبتنی بر صدا شویم، مینشانیم.
http://bit.ly/dxgn477
(زمان حدودی مطالعه، ۷ دقیقه)
نویسنده: نیما حکیمرابط
#اصول #رابط_کاربری #طراحی_مبتنیبر_صدا
@Dexign فلسفه دیزاین
ـــــــ
صدا همچنان یکی از مباحث پرطرفدار، همراه با رشد سریع است. پیش بینی شده که صنعت بلندگوهای هوشمند در سال ۲۰۱۹ دارای نرخ رشد ۶۳ درصدی نسبت به سال گذشته است. این پیشبینی، بلندگوهای هوشمند را سریع ترین دستگاه های ارتباطی در سال ۲۰۱۹ میدانند.
در حال حاضر مردم عمدتا از دستگاههای Alexa و Google Home خود فقط برای پخش موسیقی و بررسی آب وهوا استفاده میکنند. همراه با رشد بازار، نیاز است که دستگاههای اولیه از این پیشرفت تبعیت کنند و نقش مفیدتری در زندگی روزمره مردم ایفا نمایند.
در مسیر پیشرفت، بیشتر از همیشه صنعت نیاز به دیزاینرهایی دارد که بتواند برنامههای صوتی مفید و کاربرپسند ایجاد کنند. در این مسیر دیزاینرها میتواند تجربه مبتنی بر صدای خود را از متوسط به جادویی بیابند، گرچه با این چالش مواجهند که باید تمام زمینههای حریم خصوصی، امنیت و اخلاق را درنظربگیرند و رمز ادامه مسیر ایجاد تعادل بین امنیت و قابلیت استفاده است.
امروز شما را پای مقاله ای خواندنی درباره اینکه چگونه با اصلاحات ساده تبدیل به یک دیزاینر مبتنی بر صدا شویم، مینشانیم.
http://bit.ly/dxgn477
(زمان حدودی مطالعه، ۷ دقیقه)
نویسنده: نیما حکیمرابط
#اصول #رابط_کاربری #طراحی_مبتنیبر_صدا
@Dexign فلسفه دیزاین
ـــــــ
Invisionapp
You already know how to design for voice-based UIs | Inside Design Blog
Many of the same principles that govern the design of conventional user interfaces translate smoothly to this new voice-first frontier.
#پست_مجدد این پست تا به حال بیش از ۳۹۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد