زمان مبحث خیلی بزرگ و پیچیده ای هست و اکثر ما تو ساخت بیشتر برنامه ها جوانب مختلفش رو نمیبینیم. ⏰

مواردی مثل UTC و Unix TIme و Offset و Leap و خیلی چیزای دیگه رو بدرستی نمیشناسیم. ⏳

فرق Instant و Duration و Interval و Period رو درست نمیدونیم. 🤷🏻‍♂️

بدون توجه به دونستن بعضی از این موارد میایم تاریخ هارو ذخیره میکنیم ، به هم تبدیل میکنم ، بهشون زمان های دیگه رو اضافه و کم میکنیم ; در حالی که همین کارهای بنظر ساده میتونن مشکل ساز بشن. ⚠️

بعنوان مثال اینکه اول به یک تاریخ ،ابتدا 3 روز و بعد 1 ماه اضافه کنیم و اینکه به همون تاریخ ، اول 1 ماه و بعد 3 روز اضافه کنیم باعث بوجود آمدن 2 تاریخ متفاوت میشه و نتایج یکسان نیست. ❌

نمونه مثال در #C :

using NodaTime;

var start = new LocalDateTime(2017, 1, 27, 9, 0, 0);

var end1 = start + (Period.FromDays(3) + Period.FromMonths(1));

var end2 = (start + Period.FromDays(3)) + Period.FromMonths(1);

〰️〰️〰️

وقتی میگیم 1 ماه ، منظورمون 31 روز ، 30 روز یا 29 روزه ؟ سال های کبیسه تو تاریخ ها چطور محاسبه میشن ؟ جلو و عقب رفتن ساعت تو 6 ماه اول و دوم اونم فقط تو بعضی کشورها چطور حساب میشه ⁉️

این ها همه مباحثی هستن که موقع کار با زمان باید در نظر گرفته بشه. Reference های زیادی برای یادگیری این موارد هست و Library های زیادی مخصوص هر زبان براشون نوشته شده. ✅

دوتا از این Reference ها رو میزارم که بهترینش کنفرانس Jon Skeet هست : kutt.it/time


و رفرنس بعدی ، این سوال در Stackoverflow هست که جواب های زیاد و کاملی از افراد مختلف گرفته :

https://stackoverflow.com/q/2532729/6661314

🔰 یه نکته :
در مورد async فقط عملیات IO bound بهتره async بشن و اگه عملیات CPU bound رو async کنیم، عملا اون ازاد شدن ترد جاری رو نخواهیم داشت
حالا عملیات IO bound فقط میشن کار با Network و HDD و Database که بازم میشه همون هارد
نکته ای که وجود داره اینه که کلاس هایی متد MemoryStream که عملا فقط توی حافظه رم دیتا رو میریزند و می خونند، عملا متد های async شون، async واقعی نیستند و عملیات به صورت sync انجام میشه و نهایتا یه completed Task بازگردونده میشه. در واقع نه تنها هیچ منفعتی نداره بلکه یه سربار اضافی و غیر لازم هم داره

حالا دلیل اینکه پس چرا متد های async رو هم بهشون اضافه کردند، به خاطر اینه که کلاس MemoryStream از Stream ارث بری میکنه و چون توی اون کلاس متد های async وجود داره پس توی اینم پیاده سازی شده صرفا واسه یک دست بودن (والبته اکثر کلاس های Stream ایی عملیات های IO Bound دارن مثل FileStream و...)

https://stackoverflow.com/a/20805616
https://stackoverflow.com/a/47283540
___________
@IranAspMvc

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

خداحافظی با خطای میلیون دلاری: NullReferenceException

پس تغییر جنجالی C# 8.0، یعنی اضافه شدن امکان Nullable Reference Types، دیگر متغییرهای Reference Type مقدار نال قبول نخواند کرد مگر نوعشان Nullable باشد.
‍‍‍‍‍‍```
Person p = null; // ERROR
Person? P = null; // OK
string s = null; //ERROR
string? s = null; OK
اینکه این ویژگی فعال باشد یا نه از طریق تنظیمات پروژه قابل تنظیم است.
این تغییر باعث می‌شود این خطای معروف از بین برود. از طرفی پروژه‌هایی که از قبل نوشته شده‌اند نیاز به تغییرات دارند. فرانک کروگر یکی از برنامه‌نویسانی است که یکی از برنامه‌های خود را کامل بازنویسی کرده و تجربیات خود را د به اشتراک گذاشته است. جدا از اینکه تجربیاتش بسیار خواندی هستند، در حین تبدیل به چالش‌هایی برخورده که نتیجه یکی از آنها پیشنهاد اضافه کردن var? به C# بوده که نتیجه‌گیری و کاربرد جالبی است.

https://praeclarum.org/2018/12/17/nullable-reference-types.html

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

http://ow.ly/paMV30nGBdD

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

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

___

دوره جدید تحلیلی بر شخصیت من


✅ مناسب برای تمامی کسانی که می‌خواهند با شناخت بهتر خود، راه موفقیت بیشتر در کسب و کار و زندگی را پیدا کنند.

✅ ۲۴ ساعت آموزش

📞 برای ثبت نام و اطلاعات بیشتر میتوانید با شماره زیر تماس بگیرید:
02188677808

و یا به اینستاگرام زیر پیام دهید👇
https://www.instagram.com/tehranmarketing_school/

🔸مکان برگزاری کلاس ها, تهران, محدوده میدان ونک است


@tehran_marketing

روانشناسی برای بیزنس - تحلیلی بر شخصیت من

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

این مفاهیم در دنیای استارتاپ‌ها و تیم‌های برنامه‌نویسی خیلی کاربردی هستن و می‌تونه تاثیر زیادی روی موفقیت کسب و کار بذاره.

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

https://www.instagram.com/tehranmarketing_school/

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

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


___

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

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

https://github.com/adam-golab/react-developer-roadmap?utm_source=mybridge&utm_medium=blog&utm_campaign=read_more

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

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

___

توسعه دهندگان در ارتباط با APIها همیشه با چالش‌هایی رودرو بوده‌اند مانند:
-Multiple Endpoints
- Over-fetching/Under-fetching Data
- API Versioning
این مشکلات باعث شد تا برخی متخصصین به دنبال روش‌هایی برای کاهش این چالش‌ها باشند . GraphQL یکی از این راهکارهاست که در سال 2012 توسط facebook ارائه شد.
از نکات مهم این است که یک پرس و جو را به API خود ارسال کنید و دقیقا همان چیزی که نیاز دارید را دریافت کنید ، نه اطلاعات اضافه را که هر API ممکن است در خروجی خود ارسال کند. لینک زیر یک فیلم با عنوان: "Moving Existing "API From REST To GraphQL است که نگاه جالبی نسبت به موضوع دارد:

https://www.youtube.com/watch?v=broQmxQAMjM


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

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

___

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

___

اگر بخواهیم امروز یک stack برای ۳ سال آینده انتخاب کنیم؟

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

من تصمیم گرفتم این مستند رو روی گیت‌هاب درست کنم تا هم در اختیار همه باشه و هم بتونم از نظر همه شما استفاده کنم. اگر فکر می‌کنید در انتخاب stack تا حدودی شبیه هم فکر می‌کنیم خیلی خوشحال می‌شم تو تکمیلش بهم کمک کنین. تو گیت‌هاب نظراتتون رو به صورت issue مطرح کنین تا در موردشون بحث کنیم و یا حتی تغییراتی رو که به نظرتون میاد رو به صورت pull request بفرستید واسم.

https://github.com/mehrandvd/general-stack

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

http://ow.ly/DaUO30oz4z2

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

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


___

این ویدئوی ۱ دقیقه‌ای، خلاصه‌ای از سخنرانی تدکس مهران داودی هست. نسخه اصلی این TEDx Talk حدود ۱۸ دقیقه است. برای دیدن ویدئو کامل در صفحه رسمی تدکس در یوتیوب، می‌تونید لینکی که تو پیام زیر هست رو ببینید.

👇👇👇👇

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

یکی از چیزهایی که انتقالش خیلی سخته، انتقال درده! خیلی سخته یه یکی توضیح بدی چطور درد می‌کنه! یه مفهوم بی‌ربط دیگه هم هست که به نظر همینقدر سخته: انتقال مهارت‌های کار تیمی! تو این TEDx Talk توضیح دادم که چطور یه قسمت از مغزمون به نام Mirror Neurons (که خیلی هم غافلیم ازش) می‌تونه کمک کنه این کارهای خیلی سخت رو، به حتی بدون صحبت کردن انجام بدیم!

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

لینک ویدئوی کامل در صفحه رسمی تدکس در یوتیوب: https://www.youtube.com/watch?v=DfTuWdPV6JU

در صورت باز نشدن، این ویدئو در آپارات هم آپلود شده.

✅ معرفی کتابخانه CacheManager

این کتابخانه تمامی ابزار های لازم برای فرایند #Caching را یکپارچه کرده و در اختیار ما میگذاره.

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

قابلیت ها :
🔹امکان استفاده از کش پروایدر های مختلف InMemory مانندMemoryCache و System.Runtime.Caching
🔸امکان استفاده از کش پروایدر های مختلف Distributed مانند Memcached، Redis و Couchbase
🔹امکان استفاده از ابزار های Serialization مانند : Binary، Json ، Bond و ProtoBuf گوگل که جز سریع ترین هاست
🔸لاگ تمامی عملیات ها بر اساس Logging موجود در NET Core
🔹قابلیت اعمال تنظیمات بر اساس Configuration موجود در NET Core و App/Web.config و نیز کد نویسی
🔸 امکان فراخوانی متد ها به هنگام رخ داد (Event) های مختلف مانند OnGet, OnAdd, OnRemove و...
🔹قابلیت استفاده از کش های چند لایه ای
🔸مدیریت خودکار مباحث Expiration در کش های چند لایه
🔹قابلیت Sync کردن دیتا ها در کش های چند لایه
🔸امکان ثبت گزارشات (Statistics) و معیار های پرفرمنسی (Performance Counters)

همچنین این کتابخانه ضمن رعایت نکات پرفرمنسی و Best Practice های کشینگ، امکان استفاده ایمن و یکپارچه برای ما فراهم میکنه

https://github.com/MichaCo/CacheManager

در حال حاضر این کتابخونه و کتابخونه EasyCaching که قبلا معرفی کردیم، بهترین کتابخانه های Cache Integration هستند
@IranAspMvc

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

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

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

https://www.reactivemanifesto.org

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

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

___

یه بنده خدایی با قابلیت جدید 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/

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

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

___

دیزاین به احترام حریم خصوصی

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

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

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

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

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

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

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

http://bit.ly/dxgn467

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

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

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

___

❇️ نحوه ساخت اپلیکیشنهای 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

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

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

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

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