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

تئوری اسب مرده!

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

یک ضرب‌المثل قدیمی هندی می‌گوید: اگه دیدین سوار یه اسب مرده هستید، بهترین استراتژی اینه که پیاده شین.

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

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

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

در پست زیر از بلاگم در مورد این مفهوم صحبت کردم.

http://mehrandvd.me/2018/06/27/the-dead-horse-theory/


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

http://ow.ly/AGJa30kQv8N

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

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


___

چگونه یک نیروی جدید به تیم اضافه کنیم.

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

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

به نظرم این مدل برای تیم‌های نرم‌افزاری و تیم‌های استارتاپی که در حال scale کردن هستن، کاملا الگوی مناسبیه.

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

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

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

___

ابزارهای دورکاری تیم های چابک

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

29 ابزار برای دورکاری تیم های چابک
https://luis-goncalves.com/tools-distributed-agile-retrospectives/

صدایم را بشنو

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

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

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

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

اگر شما هم تجربیات مشابهی در این زمینه دارید، در بخش نطرات، آنها را با ما به اشتراک بگذارید.


http://bit.ly/dxgn554


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

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

#تجربه #رفتارشناسی #جلسه

@Dexign فلسفه دیزاین



______

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

تفاوت بین Site Reliability Engineering و Engineering DevOps مطلب جالبی‌ست. با آنکه با هم تفاوت دارند اما شبیه به هم هستند. اگر بخواهیم با دنیای OOP مقایسه کنیم SRE شبیه کلاس‌ها است و DevOps شبیه اینترفیس‌ها . SRE روابط بین دپارتمان‌های تولید و عملیات را به لحاظ همکاری و به اشتراک گذاری داده ها تنظیم می‌کند .

لینک زیر تفاوت این دو را به خوبی بیان می‌کند :

https://www.bmc.com/blogs/sre-vs-devops/

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

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

___

هشت روش برای مدیریت اثربخش بکلاگ محصول

روش اول
User story mapping

توضیحات بیشتر

http://blog.scrum.ir/2017/09/story-mapping/

@iranagile

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

چطور برنامه‌نویسی موازی را برای مادربزرگتان توضیح دهید!؟

برنامه نویسی موازی (Parallel Programming) و برنامه نویسی ناهمگام (Asynchronous Programming) مفاهیم نسبتا جدیدی در دنیای برنامه‌نویسی هستند که برای اغلب برنامه‌نویسان جدید است. همه در مورد آن شنیده‌انم ولی اغلب واضح نیست که دقیقا چیست و چرا سخت است. یک مفهوم پایه برای درک این مفاهیم پایه Thread یا نخ است. نخ‌ها مفاهیمی هستند که وظیفه انجام کارها روی CPU را دارند. در دنیای ما انسان‌ها کسانی هستند که کار انجام می‌دهند. مقاله زیر مفهوم «نخ» را به «انسان» شبیه دیده‌است و سعی کرده‌است مفاهیم پیچیده دنیای برنامه‌نویسی را با مفاهیم ساده‌ دنیای ما انسان‌ها توضیح دهد.

http://mehrandvd.me/2016/04/18/parallel-programming-grandmother/


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

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



___

🔸مهران داودی، مدیرعامل ملک‌رادار یادداشتی به نام «دورکاری شوآف نیست» نوشته و در آن از تجربه موفق دورکاری تیم ملک‌رادار پس از ۳ سال می‌گوید.

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

🔸او از سوال‌هایی که در این مدت بخاطر دورکاری تیم ملک‌رادار می‌شنید می‌گوید، سوال‌هایی مانند اینکه چطور اعتماد می‌کنید که دارد کار می‌کند؟ یا چطور می‌فهمید چقدر کار می‌کند؟ و جوابی که به این سوال‌ها می‌دهد این است: «باید با مدل ذهنی جدید به مسائل نگاه کنیم و ابزارها، تکنولوژی‌ها، عادت‌ها و فرهنگی که این محیط جدید نیاز دارد را در خودمان بسازیم و خلق کنیم.»

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

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

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

🆔 @peivast

🔗یادداشت مدیرعامل ملک‌رادار را از طریق لینک زیر بخوانید:
http://pvst.ir/7l1

یادداشت #مهران_داودی در مورد دورکاری و «مدیریت تیم ارواح» که در سایت «پیوست» منتشر شده. 👆👆

لینک یادداشت: http://pvst.ir/7l1

یادداشت را بخوانید و نظر خودتان را در مورد تجربه «دورکاری» و «مدیریت تیم ارواح» تو کامنت‌ها بنویسید برامون.

سوزنی به خود با مهارت‌های نرم

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

در مقاله‌ی امروز می‌خواهیم با سه مورد جامع، این مهارت‌ها که به مهارت‌های نرم (Soft Skills) نیز معروف هستند، آشنا شویم و آن‌ها را تمرین کنیم.

۱- یادگیری اینکه چطور عمل کنیم
۲- یادگیری اینکه چطور خودمان را با تغییر وفق دهیم
۳- یادگیری اینکه؛ چطور یاد بگیریم؟

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


http://bit.ly/dxgn556


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

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

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

#رشد_شخصی #مهارت_نرم #تغییر #یادگیری

@Dexign فلسفه دیزاین


_____

🚀 سه گانه تحول چابک
چگونه در عمل تحول چابک را انجام دهیم؟


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

در این سه گانه اول تا آخر این تحول همراه مثال عملی آورده شده است.

🚀 چارچوب عملی تحول چابک

قسمت اول:
🎯 مقصدت را بشناس
اولین دلیل شکست خوردن تحول چابکی، خود چابکی است. اینکه چابک را برای صرفا چابک میخواهیم. اما واقعا برای چه نیاز به چابک داریم؟ دردی که میخواهیم آن را رفع کنیم چیست؟ فرصتی که میخواهیم بدست آوریم چیست؟

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

http://bit.ly/38yuIaO

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

http://bit.ly/2IrlP8b

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

http://bit.ly/2TxW64s

@iranagile

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

یکی از مباحثی که همیشه در تشکیل تیم‌های نرم‌افزاری مطرح است، انتخاب زبان برنامه‌نویسی و یا تکنولوژی‌های مورد استفاده است. مقایسه محصولات موفق و نا موفق نشان می‌دهد هیچکدام از آنها صرفا با یک تکنولوژی و یا یک زبان خاص نوشته نشده‌اند. برای مثال سیستم‌های موفق زیادی وجود دارند که با Java و یا C# نوشته شده‌اند. همچنین سیستم‌های بی کیفیت زیادی نیز وجود دارد که با Java و یا C# نوشته شده‌اند. این حقیقت نشان می‌دهد دلیل موفقیت یا شکست سیستم‌ها نمی‌تواند زبان برنامه‌نویسی باشد. مقاله زیر توضیح می‌دهد که چطور طرز فکر برنامه‌نویس‌ها موفقیت و یا شکست یک سیستم را رقم می‌زند.

http://mehrandvd.me/2015/10/15/software-quality-comes-from-people-not-languages/

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


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

___

❇️ اگه هنوز براتون سواله که MongoDb یا مثلا SqlServer ❓❗️

اگه نمیدونین تئوری CAP چیه اول اینجا رو مطالعه کنین

وقتی از نگاه تئوری CAP دیتابیس mongo رو بررسی کنیم
مونگو تو شرایط مختلف trade-off متفاوتی از C و A و P رو فراهم میکنه

🔶 از نگاه Consistency :
مثلا وقتی به صورت Distribute ازش استفاده نشه Strong Consistent هست پس Consistency رو داره
ولی وقتی به صورت Distribute ازش استفاده بشه (مثلا دیتا از replica ها خونده بشه) Eventual Consistent هست پس Consistency رو فدا میکنه

🔷 از نگاه Availability:
وقتی از مونگو به صورت توزیع شده (Replica-Sets) استفاده بشه، high availability خوبی رو فراهم و در صورت دان شدن Primary Node سریعا یک node دیگه جایگزین میشه ولی در این حالت Consistency فدای Availability میشه

🔶 از نگاه Partition Tolerance:
توسط قابلیت Replica-Sets عملا Partition Tolerance فراهم است منتها تا زمانی که "بیش از نیمی" از Node ها به یک دیگر متصل باشند. در این حالت سیستم Primary Node جدید رو انتخاب میکنه
ولی اگر Node های ثانویه به اندازه کافی نباشند همچنان امکان read وجود داره ولی دیگه امکان write وجود نداره. پس دراین حالت Availability برای Consistency فدا میشه

🔰 نتیجه گیری :
✔️ اگر توزیع نشده استفاده بشه : CA
✔️ اگر توزیع شده باشه ولی اکثریت node ها در دسترس باشند : AP
✔️ اگر توزیع شده باشه ولی کمتر از نصف node ها در دسترس باشند : CP



✅ در نهایت ویژگی های خوبی که باعث میشه Mongo انتخاب بهتری نسبت به دیتابیس SQL/Relational باشه ایناس :

1️⃣ شما نیاز به مقیاس پذیری بالا به صورت Horizontal Scaling دارید (توسط قابلیت Replica-Set و Sharding مونگو)
در این حالت معمولا Consistency فدا میشه پس باید دقت داشت که این روش برای دیتا های حساس که به یکپارچگی و ثبات بالا نیاز دارند مناسب نیست، مثل برنامه های حسابداری و بانکی

2️⃣ دیتای شما ساختار (Schema) مشخصی نداره و به انعطاف پذیری بالا نیاز دارید (به خاطر Schema-less بودن مونگو)
در این حالت باید توجه داشت که متفاوت بودن ساختار رکورد (داکیومنت) ها میتونه احتمال خطا توی سیستم رو افزایش بده پس باید در سطح کد نویسی حواسمون بهش باشه

3️⃣ دیتابیس Mongo برای ذخیره سازی و بازیابی دیتا های حجیم و "مرتبط" بسیار مناسبه و پرفرمنس بالایی داره، چون تمام دیتای مرتبط به یک سند داخل خودش ذخیره میشه و نیاز به Join خیلی کمتر احساس میشه

4️⃣ دیتابیس Mongo به خاطر ساختار و سادگی ایی که داره Performance Tuning و Optimization های حرفه ای که نیاز به DBA داشته باشه خیلی کمتر توش احساس میشه پس اگه میخواین خیلی درگیر کار های DBA ایی نشین Mongo گزینه مناسبیه
___________________
@DotNetZoom

مصوّرسازی داده‌ها

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

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

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

اما انتخاب نوع این مجسّم‌سازی برای استفاده، صرفاً بحث زیبایی‌شناختی نیست، و نه حتی کاملاً شخصی هم نیست. انتخاب اشتباه می‌تواند بیننده را به بی‌حوصلگی و سردرگمی سوق دهد. بدتر از این، مصوّرسازی نادرست می‌تواند بین شما و مخاطبانتان بی‌اعتمادی ایجاد کند. به قول Stephen Few مبتکر و مشاور خبره‌ی این عرصه:
“اطلاعات ارزشمندی که در دستان شماست، داستان مهمی برای گفتن دارد و این وابسته به شماست که به آن‌ها صدایی واضح و قانع کننده بدهید”

حال که با اهمیّت فراوان نحوه‌ی دیزاین داده‌ها آشنا شدید. شما را به خواندن مقاله‌های موفق زیر که اصول این عرصه را به خوبی توضیح می‌دهد تشویق می‌کنم:

۱- http://bit.ly/dxgn561-1

۲- http://bit.ly/dxgn561-2

پ.ن: شرکت‌های بسیاری از جمله Google و IBM به ساختن راهنماها و استایل‌شیت‌ها، مانند دیزاین سیستم‌ها پرداخته‌اند که از طریق لینک‌های زیر می‌توانید به آن‌ها دست پیدا کنید:

۱- https://www.ibm.com/design/v1/language/experience/data-visualization/

۲- https://material.io/design/communication/data-visualization.html

۳- https://medium.com/nightingale/style-guidelines-92ebe166addc

(زمان حدودی مطالعه مقاله‌ی اوّل: ۶ دقیقه و مقاله‌ی دوّم: ۱۰ دقیقه)

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

#مصورسازی_داده_ها #نمودار #داده #دیزاین_اطلاعات

@Dexign فلسفه دیزاین


ــــــ

💻 مایکروسافت در دسامبر سال 2019 در کنفرانس بیلد اعلام کرد که NET 5.0. انتشار بزرگ بعدی در خانواده NET. است و در تاریخ نوامبر 2020 وارد بازار می‌شود.

📌در این پست به معرفی اجمالی NET 5. پرداخته می‌شود:

📓 فریم‌ورک NET 5.0. ترکیبی از بهترین ویژگی‌های هسته‌های NET Core .NET Framework Xamarin و Mono است.

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

تمامی ویژگی‌های قبلی کماکان وجود دارد:
- متن باز و Community-Oriented بودن در گیت هاب
- پیاده سازی Cross-Platform
- [ادامه ویژگی‌ها به همراه ویژگی‌های جدید ... ].

📓دلیل جهش مایکروسافت از NET Core 3. به 5 جلوگیری از سردرگم شدن برنامه نویس‌هاست.
به این دلیل که برنامه‌نویسان دات نت فریم‌ورک از ورژن های 4x استفاده می‌کردند و اگر به جای Net 5.0. از Net 4.0. استفاده می‌شد، امکان داشت سر درگمی برای کاربران به وجود آید، بنابراین دات نت Core نسخه‌ی 4 نخواهیم داشت.

📓دو مورد اساسی که در این ورژن اتفاق می‌افتد و باید به آن‌ها اشاره شود:
۱- هماهنگ شدن و تلفیق تیم Unity با دیگر برنامه‌نویسان دات نت.
۲- ارائه نسخه نهایی Blazor

📎[منبع] 📎[تصویر]
〰️〰️〰️〰️〰️〰️〰️〰️

📓لینک های مرتبط :
📎 Mono: from Xamarin to WebAssembly, Blazor, and .NET 5 - Q&A with Miguel de Icaza
📎Did ASP.NET Web Forms Need to Die?
📎Not planning now to migrate your .NET 4.8 legacy, is certainly a mistake
📎Add Mono to the repository #1912
📎 .NET 5
📎ساماندهی مخازن کد NET Core. برای کار بر روی NET 5.
📎.NET Core master branches have switched to "5.0" #118
📎What Does .NET 5 Mean To You
📎Will .NET 5 include WCF?
📎.NET 5 The Future is Now

〰️〰️〰️〰️〰️〰️

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، برروی دکمه «نظرت را بگو» کلیک کنید.

#حامد_حاجیلو (http://bit.ly/2IVjfYD)

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

___

♨️ یک تغییر بزرگ: حذف دستور new از زبان‌های C# و Java ⁉️

بالاخره پس از مذاکرات و صحبت‌های زیاد در یک اقدام هماهنگ خالقان C# و Java تصمیم گرفتند دستور new را از این زبان‌ها حذف کنند. این تصمیم به این دلیل گرفته شد که از نظر طراحان این زبان‌ها همه Object Instantiation ها همیشه باید از طریق Dependency Injection انجام شود و اصولا در یک برنامه خوب برنامه‌نویس نباید خودش یک شی را ایجاد کند.

// Not a valid code anymore. 
Person p = new Person(); 

// New dependency injection syntax.
Person p = new.Resolve<Person>(); 

این تصمیم اولین تصمیم هماهنگ شده و همزمان بین تیم‌های توسعه زبان Java و C# است و Anders Hejlsberg و James Gosling هر دو در مورد این تصمیم بسیار خوشحالند.

با توجه به اینکه این تصمیم در روز اول آوریل (۱۳ فروردین) گرفته شد و نسخه Visual Studio 2019 نیز در همین روز منتشر شد، این تغییر در نسخه جدید C# 8.0 اعمال شده و باید از مدل جدید آن استفاده کنید.
در جاوا هم طبق برنامه‌ریزی این ویژگی در Java 15 اضافه خواهد شد که در سال ۲۰۲۵ ریلیز خواهد شد.

برای اطلاعات بیشتر می‌توانید مقاله‌ای که در این مورد در لینک زیر نوشته شده‌است را بخوانید.

۱۳ بدرتان مبارک!

http://mehrandvd.me/2019/04/01/a-huge-change-in-java-and-c/

http://ow.ly/MldR30ojXpI

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

http://ow.ly/6RyP30ojWAP

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

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

___

مفهوم Collectionها در جاوا و نحوه استفاده از آن‌ها مبحث بسیار جذاب و مهمی برای هربرنامه نویس جاوا (یا حتی غیر جاوا) است. همانطور که می‌دانیم مبحث ساختمان‌های داده در جاوا به دو قسمت عمده Collection و Map تقسیم می‌شود که قسمت‌های اول به Collectionها اختصاص دارد . خود collection ها هم به List ها، Setها و ueue ها تقسیم می‌شود.
لینک زیر مقدمه‌ای بر این قسمت ارائه می‌دهد:

https://bit.ly/2x0dMx2

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

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

___