دنیای AR یا Augmented Reality باعث ایجاد مفاهیم جدیدی در UI/UX شده‌است. توان خلق موجودیت‌ها در فضای اطراف کاربر امکانی است که قبلا وجود نداشته و به همین دلیل ظهور AR باعث ایجاد تجربیات جدیدی در دنیای UX شده‌است.
برای مثال در لینک زیر یکی از طراحان ارشد هولوگرافیک توضیح می‌دهد که در نسخه‌های اولیه نرم‌افزار طراحی برای خلق اشیا سه بعدی، از یک «میز چهارگوش» مجازی استفاده شده بود که کاربر روی آن شروع به طراحی می‌کرد (مثلا طراحی یک اسباب‌بازی). پس از تست‌های UX متوجه شدند چهارگوش بودن میز باعث می‌شود کاربران بیشتر یک سمت میز بایستند و کمتر دور شیی که طراحی می‌کنند بچرخند. به همین دلیل در نسخه‌های بعدی از یک میز مجازی «گرد» استفاده شد. نتیجه عالی بود، کاربران دیگر یک جای ثابت نمی‌ایستند و تقریبا هر دفعه از یک زاویه جدید محصول خود را می‌بینند.

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

https://developer.microsoft.com/en-us/windows/holographic/case_study_-_3_holostudio_ui_and_interaction_design_learnings

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. مالک محصول بزرگ در مقابل مالک محصول کوچک (Agile Product Management)

https://t.me/SoftwarePhilosophy/1149

۲. قورباغه را دوباره اختراع نکنید!

https://t.me/SoftwarePhilosophy/1151

۳. الگوی Async Retry Pattern

https://t.me/SoftwarePhilosophy/1153

۴. معرفی کتاب‌های بی‌ربط به دیزاین (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1154

۵. تجربیات و درس‌های یک طراح ارشد پروژه‌های هولوگرافیک

https://t.me/SoftwarePhilosophy/1156

ـــــــــــ

@SoftwarePhilosophy

یکی از مهمترین چالش‌ها در الگوریتم‌هایی که با حجم زیادی از آرایه‌ها کار می‌کنند، کپی کردن قسمت‌هایی از آرایه برای انجام یک کار روی آن است. برای مثال وقتی می‌خواهید نصف دوم یک آرایه را به یک متد پاس بدهید، عموما مجبورید از نصف دوم آرایه یک کپی بگیرید و به متد پاس بدهید. سربار کپی همیشه یکی از مهمترین چالش‌های performance در الگوریتم‌ها بوده است.
یکی از امکانات جذابی که به C# 7.2 اضافه شده، مفهوم Span<T> است. با استفاده از این تایپ جدید که بر اساس مفاهیم پیچیده‌ای بنا شده، به راحتی می‌توانید یک قسمت از یک آرایه را بدون اینکه کپی کنید جدا کنید و از آن استفاده کنید.

در مقاله زیر Stephen Toub که یکی از معماران اصلی امکانات Parallel Programming در .Net است، بسیار مفید و دقیق در مورد Span<T> و Memory<T> صبحت کرده و حتی در مورد قسمت‌هایی از لایه‌های زیرین این تایپ‌ها توضیح داده که چطور کد آنها پیاده‌سازی شده‌است.

https://msdn.microsoft.com/en-us/magazine/mt814808.aspx


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

http://ow.ly/oEWA30ik0Yp

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

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


___

🔵 چرا کارها در انتهای اسپرینت تمام نمی‌شوند؟

سه دلیل عمده اینکه چرا کارها در انتهای اسپرینت تمام نمی‌شوند:

1- تسک سوییچ: اینکه فرد بین تسکهای مختلف خود مجبور به سوییچ کردن است و نمی تواند یک کار کامل انجام دهد و سپس کار بعدی را شروع کند.

2- افراد بنابر تخصص از همه جدا شده اند: مثلا فرانت اند، بک اند، تحلیل. در این صورت تسک های نفرات از همه جدا می شود، این روش برای مشغول نگه داشتن افراد عالی است ولی برای تمام شدن کلی کار و نتیجه گرفتن، میتواند خوب نباشد.

3- آیتم های اسپرینت بزرگ هستند: آیتم هایی که وارد اسپرینت می شوند خوب شکسته نشده اند و معمولا چند اسپرینت به طول می انجامند.

https://goo.gl/Fwx3c7

@iranagile

لاگ ها - یکپارچه سازی

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

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

1. قابلیت جستجوهای پیشرفته، گزارش سازی و کوئری زدن بر روی آن ها وجود ندارد.
2. در برنامه های پر ترافیک ثبت لاگ بر روی فایل ترافیک I/O زیادی را به سیستم تحمیل می کند.
3. اگر سامانه متشکل از چند سیستم جدا از هم باشد، لاگ های پراکنده ای خواهیم داشت که هر کدام در یک محل جدا و غیریکپارچه قرار گرفته اند.
4. برای خواندن لاگ ها نیاز به دسترسی به مستقیم به سرور خواهید داشت.

برای حل مشکل یکپارچگی لاگ ها، خیلی از سیستم های پرترافیک از پلتفرمی به نام ELK استفاده می کنند. اما برای سیستم های کوچک تر و یا تیم هایی که در عین کیفیت از پیچیدگی فراری هستند، می توان از ابزار فوق العاده و البته رایگان SEQ استفاده کرد. این ابزار به شما امکان می دهد تا لاگ ها را از همه سیستم های تان یکجا جمع کنید، بدون نیاز به دسترسی مستقیم به سرور و با مرورگرتان لاگ ها را در یک پنل زیبا و کاربردی مشاهده کنید و با زبانی شبیه به SQL در میان لاگ ها جستجو کرده و گزارش و نمودار بسازید و از داشبورد به نسبت خوب و کاربردی بهره مند شوید. البته برای اینکه بتوانید در لاگ ها جستجوهای پیشرفته داشته باشید، باید لاگ های تان ساختارمند باشند. در قسمت بعدی راجع به لاگ های ساختارمند صحبت خواهیم کرد.

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

* ابزار SEQ توسط توسعه دهنده کتابخانه پرقدرت Autofac و Serilog توسعه داده شده است.

* دانلود ابزار SEQ
https://getseq.net/Download

*توضیحاتی در مورد SEQ
https://blog.getseq.net/hello-seq-4-0-dashboards-alerts-more-improvements/

https://blog.getseq.net/seq-4-2-rtm/

* پلتفرم ELK - پرقدرت ولی به نسبت پیچیده از حیث راه اندازی و نگهداری
https://www.elastic.co/webinars/introduction-elk-stack

@irandotnet

تصمیم دُرُست را دُرُست بگیریم

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

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

مقاله امروز از Brandon Chu، راهبر محصول در Shopify است. Brandon تصمیم‌ها را به دو دسته تقسیم کرده و برای گرفتن آن‌ها، در بهینه‌ترین زمان و با بهترین خروجی توضیحاتی می‌دهد.

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

https://blackboxofpm.com/making-good-decisions-as-a-product-manager-c66ddacc9e2b

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

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

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. آشنایی با مفهوم Span<T> در C# 7.2

https://t.me/SoftwarePhilosophy/1158

۲. چرا کارها در انتهای اسپرینت تمام نمی‌شوند؟ (Iran Agile)

https://t.me/SoftwarePhilosophy/1159

۳. لاگ ها - یکپارچه سازی (Iran .Net)

https://t.me/SoftwarePhilosophy/1160

۴. تصمیم دُرُست را دُرُست بگیریم (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1161

ـــــــــــ

@SoftwarePhilosophy

یادگیری مفاهیم پایه یا تکنولوژی های جدید

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

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

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

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

* اسکات هنسلمن https://www.hanselman.com/blog/YouGotThisYouKnowTheFundamentalsYouAreALearnerPlusTheImpostersHandbook.aspx

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

* مَتیو جونز : همه کدها دورریختی اند

https://exceptionnotfound.net/all-code-is-disposable-just-like-it-should-be/

* مَتیو جونز : من از 9 تا 5 کار می کنم | شما هم می توانید

https://exceptionnotfound.net/i-am-a-9-to-5-developer-and-so-can-you/

* مطلبی در مورد سندروم Imposter و اینکه تحقیقات نشان می دهد برنامه نویسانی که مدام کار می کنند، دچار مشکلات روحی متعددتر و بازدهی پایین تری هستند. عاشق برنامه نویسی بودن به معنی هفته 100 ساعت کار کردن نیست.

http://www.businessinsider.com/syndromes-drive-coders-crazy-2014-3

@irandotnet

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

گرفتن امتیاز ۴۰۰ در Telegram Lumberjack با استفاده یک بات برنامه‌نویسی شده!!!

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

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

___

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

لینک زیر یکی از پیاده‌سازی‌های ممکن برای گرفتن امتیازهای بالا در Telegram Lumberjack را شرح داده‌است.

http://mehrandvd.me/2016/10/30/cheating-telegram-lumberjack/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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


___

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

فلسفه Spacive Design جایگزینی برای Responsive Design

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

هنوز خیلی زود است که بتوان در مورد آینده طراحی UI/UX اظهار نظر کرد. ولی به نظر من یکی از آینده های محتمل برای طراحی UI/UX‌ نسل آینده نرم‌افزارها طراحی «فضاگرا» است. طراحی فضاگرا نوعی طراحی نرم‌افزار است که به آن این امکان را می‌دهد تا قسمت‌های مختلف خود را در فضای اطراف کاربر پخش کند. برای مثال فرض کنید هنگام کار با فیسبوک، تایم‌لاین را روی دیوار روبروی خود ببینید و نوتیفیکیشن‌ها رو روی ساعد خود ببینید. به این ترتیب نرم‌افزار فیسبوک توانسته در فضای اطراف شما مستقر شود.

http://mehrandvd.me/2016/07/12/hololens-spacive-design-new-era-uiux/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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


___

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

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

http://mehrandvd.me/2016/06/18/covariant-and-contravariant/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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



___

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

وابستگی چیست و چرا اتفاق می افتد؟

در چند شرکت اخیر که همکاری با آنها داشتم مانند سداد، علی بابا، بامیلو …، وابستگی جزئی از کار شده است، وابستگی ها شامل وابستگی فراتیمی (وابسته به تیم های دیگر در شرکت) یا فرا شرکتی (وابسته به شرکت های دیگر) است.

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

یا سرویس خرید بلیط هواپیما که عمدتا شرکت های هواپیمایی برای شرکتهای فروش آنلاین بلیط هواپیما فراهم می کنند.

یک نوع دیگر، وابستگی فراتیمی است، مثلا تیم دیتا باید یک سری داده برای تیم های دیگر فراهم کند.

مشکل وابستگی چیست؟

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

اما با این نوع وابستگی چگونه برخورد کنیم؟

قانون اول وابستگی- شروع نکردن پیاده سازی تا رفع وابستگی:

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

قانون دوم وابستگی- برنامه ریزی یکم رو به جلو

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

ساختار سازمانی باعث وابستگی می شود

یکی از دلایل وابستگی، ساختار سازمانی شرکت است، یکی از مثال ها در چند شرکت اخیر، ساختار فرانت اند و بک اند، بوده. یعنی تیم فرانت اند برای انجام کار نیاز به تیم بک اند دارد، و این باعث پاس کاری بسیار زیاد در بین تیم ها می شود، که راه حل ایجاد تیم های فرا-وظیفه ای یا Cross Functional است.

در برخی تجربیات دیگر، جدا بودن، تیم تست از تیم های پیاده سازی، یا تیم تحلیل، یا تیم دیتا. راه حل بسیاری از این موارد، تجدید نظر در ساختار سازمانی است، یا اگر امکان این کار وجود ندارد، باید به قانون یک و دو رجوع کنیم.

https://goo.gl/NnJCst

@iranagile

#خلاصه_مطالب «فلسفه نرم‌افزار» در هفته گذشته:

۱. یادگیری مفاهیم پایه یا تکنولوژی های جدید (Iran .Net)

https://t.me/SoftwarePhilosophy/1163

۲. نوشتن بات‌ برای بازی‌های کامپیوتری

https://t.me/SoftwarePhilosophy/1165
https://t.me/SoftwarePhilosophy/1167

۳. فلسفه Spacive Design جایگزینی برای Responsive Design

https://t.me/SoftwarePhilosophy/1169

۴. آشنایی با مفاهیم Covariance و Contravariance

https://t.me/SoftwarePhilosophy/1171

۵. با وابستگی‌ها چه کنیم؟ (Iran Agile)

https://t.me/SoftwarePhilosophy/1172

ـــــــــــ

@SoftwarePhilosophy

درون کمپانی های نرم افزاری چه می گذرد؟

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

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

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

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

* بلاگ تست گوگل
https://testing.googleblog.com/

* بلاگ فنی نت فلیکس | شامل مطالب خوبی پیرامون مایکروسرویس ها، استریمینگ و ماشین لرنینگ
https://medium.com/netflix-techblog

* بلاگ فنی یوتیوب
https://youtube-eng.googleblog.com/2016/05/

* بلاگ فنی گیت هاب
https://github.com/blog

* بلاگ فنی Stackoverflow | دارای مطالبی خواندنی حتی برای خواننده متوسط
https://stackoverflow.blog/engineering/

* تجربیات مایکروسافت در حرکت به سمت توسعه های سریع تر، با کیفیت تر و مقاوم تر
https://www.visualstudio.com/learn/monolith-cloud-service/

* بلاگ فنی مایکروسافت DevOps
https://blogs.msdn.microsoft.com/devops/

* بلاگ فنی فیس بوک
https://research.fb.com/blog/

(این فهرست به روز خواهد شد)

@irandotnet

چه می‌کنه این نمودار

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

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

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

https://blog.sariina.com/878-how-did-we-design-90s-charts-and-lottery

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

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

___

نکته ای در رابطه با استفاده بهینه از HttpClient


در بسیاری از موارد نیاز هست تا یک سیستم با سیستمی دیگر ارتباط برقرار کند. با فراگیر شدن وب سرویس های مبتنی بر HTTP، عمده سیستم ها با استفاده از پروتکل HTTP با یکدیگر ارتباط برقرار می کنند. این ارتباط می تواند با سرویس های داخلی سازمان، بانک، سرویس دهنده پیامک و ایمیل و یا سرویس های داخلی یک سیستم مبتنی بر Microservice و غیره باشد.

در مواردی که از HttpClient برای ارسال درخواست ها استفاده می کنیم، باید این نکته را به خاطر داشته باشیم که تنها و تنها یک نمونه از HttpClient در برنامه داشته باشیم و در همه موارد از همین یک نمونه استفاده کنیم. این یک نمونه می تواند توسط الگوی Singleton که پیشتر توضیح داده شده بود، ایجاد شود.

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

کلاس HttpClient از اساس Thread-safe طراحی شده است. یعنی می توان با داشتن یک نمونه از آن، همزمان در thread های مختلف - درخواست های مختلف کاربران در یک وب اپلیکیشن - از همان یک نمونه استفاده کرد و کار هیچ Thread ایی بر دیگری اثر نخواهد گذاشت.

* تجربه تلخ از عدم استفاده صحیح از HttpClient
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

* توصیه رسمی مایکروسافت بر ساخت یک نمونه از HttpClient و استفاده از آن در باقی نقاط برنامه:
https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=netframework-4.7

* توضیحی دقیق در مورد thread-safety کلاس HttpClient
http://www.michaeltaylorp3.net/httpclient-is-it-really-thread-safe/

@irandotnet