Software Philosophy
3.45K subscribers
160 photos
41 videos
1.54K links
چکیده‌ای از مفاهیم به روز مهندسی نرم افزار برای مهندسین نرم‌افزار.
معماری نوین نرم‌افزار، تکنولوژی‌های برنامه نویسی جدید
Download Telegram
#پست_مجدد این پست تا به حال نزدیک به ۴۰۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
خداحافظی با خطای میلیون دلاری: 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

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

https://ow.ly/paMV30nGBdD

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

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

___
Forwarded from tehran marketing school
دوره جدید تحلیلی بر شخصیت من


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

۲۴ ساعت آموزش

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

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

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


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

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

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

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

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

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

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


___
#پست_مجدد این پست تا به حال نزدیک به ۱۴۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
این روزها همه در مورد react صحبت می‌کنند و برنامه‌نویسان زیادی دوست دارند آن را یاد بگیرند اما سوالی که برای اکثر ما مطرح است این است که برای یادگیری react اول چه چیزهایی را باید بلد باشیم. این مقاله به شکلی بسیار گویا توضیح می‌دهد، برای اینکه در react استاد شوید چه مسیری را باید طی کنید.

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

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


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

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

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

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

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

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

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

https://ow.ly/DaUO30oz4z2

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

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


___
Media is too big
VIEW IN TELEGRAM
این ویدئوی ۱ دقیقه‌ای، خلاصه‌ای از سخنرانی تدکس مهران داودی هست. نسخه اصلی این TEDx Talk حدود ۱۸ دقیقه است. برای دیدن ویدئو کامل در صفحه رسمی تدکس در یوتیوب، می‌تونید لینکی که تو پیام زیر هست رو ببینید.

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

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

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

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

در صورت باز نشدن، این ویدئو در آپارات هم آپلود شده.
Forwarded from DotNetZoom (محمد جواد ابراهیمی)
معرفی کتابخانه 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
#پست_مجدد این پست تا به حال نزدیک به ۱۲۰۰ بار مشاهده شده و به نظر می‌رسد برای خوانندگان جدید کانال جذاب باشد.
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


___