اضافه کردن فیچر به نرم‌افزار غالبا ویژگی مثبتی به نظر می‌رسد. ولی وقتی تیمی دارید که قدرت بسیار بالایی دارد اضافه کردن فیچرها با سرعت خیلی زیاد خودش می‌تواند نکات منفی داشته باشد. وقتی قدرت اضافه کردن امکانات با سرعت زیاد دارید باید محتاط باشید که امکانات جدید راه‌حل‌هایی جدید برای یک مسئله حل شده نباشند. داشتن تیم قدرتمند این قدرت را به مدیران می‌دهد که بتوانند سریع ایده‌های ذهنی خود را پیاده‌سازی کنند. در این حین باید مراقب بود این امکانات با هم، همپوشانی نداشته باشند.
مثال زیر از تیم توسعه C# آورده شده‌است که در مورد کاربرد دو امکان این زبان که در نسخه‌های ۵ و ۶ اضافه شد صحبت می‌کند.

http://mehrandvd.me/2016/05/02/steady-consistent-flow-features/

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

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



___

تحقق یک رویا: پشتیبانی توکار از دات نت در همه مرورگرهای مدرن

به لطف استاندارد مدرن - و هنوز فراگیر نشده - WebAssembly، امروزه همه مرورگر های مدرن می توانند به جای اجرای جاوا اسکریپت، یک زبان bytecode استانداردِ سطح پایین و شبیه به زبان اسمبلی را اجرا کنند. استفاده از WebAssembly می تواند موجب اجرای سریع تر کد و کاهش حجم آن شود. اما مهمترین مزیت این هست که امروز می توانیم همه زبان های قدرتمند نظیر سی شارپ را به نحوی کامپایل کنیم که خروجیِ نهایی، منطیق با استاندارد webassembly باشد و به صورت native در مرورگرها دات نت را اجرا کنیم.

کامپایل سی شارپ به WebAssembly توسط تیم Mono مایکروسافت انجام شده و عمده مشکلات فنی سر راه برداشته شده اند. اما برای اینکه عملا بشود از دات نت در مرورگر ها استفاده کرد، مایکروسافت در پی پیاده سازی پروژه جاه طلبانه ای به نام Blazor می باشد. در واقع Blazor فریم ورک Client-Side مبتنی بر دات نت خواهد بود، الهام گرفته از فریم ورک های کنونی (مانند Angular و React) و رقیبی جدید برای آن ها. فریم ورک Blazor هم مانند آن ها حول مفهوم Component شکل گرفته است. کامپوننت هایی که کلاس های سی شارپی هستند و با زبان Razor توسعه داده شده اند.

استفاده از دات نت در مرورگر ها می تواند موجب این شود که کد بیشتری را بین سرور و کلاینت بتوانیم به اشتراک بگذاریم و نیاز به دوباره کاری در هر دو سمت نداشته باشیم. علاوه بر این توسعه دهندگان سی شارپ کمی بیشتر به مفهوم Full Stack Developer نزدیک خواهند شد.
همچنین با استفاده از WebAssembly می توانیم به تمام کتابخانه های موجود جاوااسکریپتی هم دسترسی داشته باشیم و محدودیتی در این زمینه وجود ندارد. همچنین می توان DOM را هم از این طریق مدیریت و دستکاری کرد.

در حال حاضر تیم AspNet عهده دار کار بر روی پروژه Blazor شده است. از نوشته های آن ها چنین بر می آید که تا نهایی شدن این پروژه هنوز باید صبر کنیم.

* گیت هاب Blazor:
https://github.com/aspnet/Blazor

* کمی فنی تر:
http://blog.stevensanderson.com/2018/02/06/blazor-intro/

* بلاگ تیم AspNet در رابطه با پروژه جدید Blazor:
https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-experimental-project/

*پادکست اسکات هنسلمن در مورد وب اسمبلی با یکی از توسعه دهنده گان فایرفاکس:
https://hanselminutes.com/581/inside-webassembly-with-mozilla-fellow-david-bryant

@irandotnet

روانشناسی شکل‌ها

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

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

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

https://uxplanet.org/knock-design-into-shape-psychology-of-shapes-6e43c6e59955

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

#بررسی #روانشناسی #شکل
@Dexign فلسفه دیزاین

___‌

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

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

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

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


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

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



___

برای "ما" لوکس و برای "آن ها" اساس

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

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

* همه تیم ها بلااستثنا از بهترین ابزار ها و روش ها برای راه اندازی Continous Integration و Continious Deployment استفاده می کنند.
* همه تیم ها مجموعه بسیار خوب و دقیقی از تست های واحدِ با کیفیت و ایزوله را طراحی کرده اند که به صورت خودکار بر روی سرورهای بیلد شان اجرا می کنند.
* همه تیم ها زیرساخت های شان را بر روی سرور های کلاد آمازون، گوگل و یا مایکروسافت مستقر کرده اند و از سرویس های آن ها بهره می گیرند.
* از بهترین و مدرن ترین پلتفرم ها برای ثبت لاگ اپلیکیشن ها و سرور ها استفاده می کنند تا به صورت دقیق رفتار کاربر و سرور را تحت نظر داشته باشند.
* برای استقرار نرم افزار از Docker و Kubernetes استفاده می کنند.
* به کیفیت کد و نام گذاری ها به شدت اهمیت می دهند و تقریبا در همه آن ها استفاده از Dependency Injection و Dependency Inversion و تقسیم بندی سیستم به لایه های درست دیده می شود.
* هر کدی که تغییر پیدا می کند، دلیل مشخص دارد و به یکی از Issue ها مرتبط شده است. هیچ تغییری بدون دلیل و غیرمستند نیست.
* بسیار درست از Git برای مشارکت در کد استفاده می کنند. کسی مستقیم در Repository ها کدی را push نمی کند. هر کس موظف هست تا تغییرات را در غالب Pull Request ارسال کند تا دیگران (یک یا دو نفر) کد را Review کرده و نظرشان در مورد تغییراتی که باید انجام شوند اعلام کنند.
* با ارسال Pull Request ها، تست ها به صورت خودکار اجرا می شوند تا reviewer ها مطمئن شوند که تغییر موجب شکست سیستم نخواهد شد.

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

⭕ درس آموخته‌های یک پروژه

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

✅ نکات بدیهی که دیر فهمیدیم:

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

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

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

💬 تمام اصول مانیفست اجایل ( و حتی اصول اخلاقی اسکرام مثل شفافیت) تزئینی نیستند. رعایت این‌ها حتی از پرداخت حقوق سر وقت هم مهم‌تره. و این اصول فقط برای برنامه‌نویس‌ها نیست. برای سازمانه.

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

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

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

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

https://goo.gl/vZr6Eb

@iranagile

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

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

http://mehrandvd.me/2016/03/28/linq-the-bad-parts/

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

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



___

پیغام خطای مزخرف «نام کاربری یا کلمه عبور شما اشتباه است.»

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

تا مدتی این دلیل برایم به اندازه کافی قانع‌کننده بود ولی بعدتر که بیشتر و بیشتر با این پیغام مواجه شدم، دیگر نتوانستم آن را قبول کنم و به عنوان کاربر برایم آزاردهنده بود.
در نهایت با سرویس Mailchimp آشنا شدم که از سال ۲۰۰۱ خدماتی را در حوزه خبرنامه ارائه می‌دهد. این سرویس تمام حق را به کاربر داده و حفاظت از اطلاعات آن‌ها را بطور کامل وظیفه خود دانسته است، لذا تمامی پیغام‌های خطایی که می‌دهد کاملا واضح و روشن هستند. دیدن سرویس Mailchimp به من این شجاعت را داد که سعی کنم در تمامی سرویس‌هایی که دیزاین می‌کنم، در کنار سود صاحبان سرویس، از حقوق کاربران نیز دفاع کنم.

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

https://hackernoon.com/username-or-password-is-incorrect-is-bullshit-89985ca2be48

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

#بررسی #روش #Login
@Dexign فلسفه دیزاین

___‌

قابلیت های جدید Entity Framework Core
* Connection Pooling *

بالاخره با انتشار نسخه نخست پیش نمایش EF Core 2.1 می توانیم بگوییم که نسخه Core کمبودهایی را که به نسبت آخرین نسخه نسل پیشین یعنی Entity Framework 6 داشت کاهش داده و حتی برطرف کرده است. فکر می کنم با انتشار نسخه نهایی EF Core 2.1 می توانیم کم کم در پروژه های عملیاتی از آن بهره بگیریم.

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

قابلیت Connection Pooling که در نسخه EF Core 2.0 معرفی شده است، می تواند در برنامه های وب کارایی برنامه شما را بی هیچ زحمتی، به مقدار قابل توجهی افزایش دهد. در بنچ مارک ساده ای که تیم EF Core منتشر کرده است، آن ها توانسته اند تا 20 درصد تعداد درخواست هایی را که می توانند پاسخ دهند افزایش دهند.

پیش از معرفی این قابلیت، برای هر درخواست جدید که به سرور می رسید ما می بایست یک DbContext جدید را می ساختیم (Instantiate) و پس از پایان درخواست هم می بایست که این DbContext را Dispose می کردیم تا منابع اش را آزاد کنیم. به این الگو One Context Per Request گفته می شد.

مشکل این روش آن می باشد که ساخت و Dispose برای نمونه های DbContext عملی سنگین و زمانگیر می باشد. برای حل این مشکل در EF Core 2.0 قابلیت جدیدی معرفی شد که به طور پیشفرض فهرستی (Pool) از DbContext های آماده به کار را پیش از شروع رسیدگی به اولین درخواست می سازد. سپس به ازای هر درخواست به جای ساخت DbContext جدید - که عملی زمانبر می باشد - از نمونه های موجود در Pool استفاده می کند و پس از پایان چرخه درخواست، DbContext به جای Dispose شدن به Pool بر می گردد تا برای درخواست دیگری استفاده شود. همه این فرایند خودکار و بدون دخالت شما صورت می گیرد.

استفاده از تکنیک و الگوی Connection Pooling یکی از روش های متداول برای استفاده حداکثری از منابع سیستم می باشد. در EF Core با پیاده سازی این تکنیک برنامه های ما فقط با تغییر یک خط کد می توانند تا حد خیلی بالایی افزایش کارایی را تجربه کنند.

* توضیحات و بنچ مارک:
https://neelbhatt.com/2018/02/27/use-dbcontextpooling-to-improve-the-performance-net-core-2-1-feature/

* بحثی در گیتهاب پیرامون مکانیزم کار این قابلیت:
https://github.com/aspnet/EntityFrameworkCore/issues/10125

@irandotnet

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

معماری جدید Migration در EF Core 1 اگر با Entity Framework Migrations کار کرده‌اید و با آن پروژه جدی انجام داده‌اید حتما در مواقعی نیاز داشته‌اید که بتوانید Snapshot دیتابیس بین دو Migration را مقایسه کنید. این کار در نسخه ۶ کار بسیار سختی بود زیرا این Snapshot در فایل Resource به ازای هر Migration ذخیره می‌شد. اتفاق خوبی که در نسخه ۷ افتاده این است که معماری آن عوض شده و ذخیره‌سازی به صورت کلاس‌هایی است که حتی از طریق کد هم می‌توانید به آن دسترسی داشته باشید.

لینک زیر این تغییر معماری رو توضیح می‌دهد تا بتوانید از آن در پروژه‌های آتی خود استفاده کنید.

http://mehrandvd.me/2016/02/18/entity-framework-core-migrations/

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


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


___

روزها نمی‌گذرند، ما آنها را می‌گذارنیم، ما آنها را خلق می‌کنیم، می‌سازیم.
سال قبل را با هم گذارندیم، خلق کردیم، ساختیم.
امیدوارم سال جدید را همانطور که می‌خواهید خلق کنید، تا آینده را با هم بسازیم...
سال نو مبارک.

مهران
http://mehrandvd.me

من در استفاده از git بیسوادم، چون هنوز با طرز تفکر قدیمی خود از آن استفاده می‌کنم!

ساختار گیت و معماری فکری آن به گونه‌ای است که می‌توان با روش‌های بسیار متنوعی از آن استفاده کرد. اینکه چه موقعی یک branch جدید ساخته شود، چه موقعی merge انجام شود و یا اینکه اصولا چند branch موازی وجود داشته باشد همه و همه به یک استراتژی و معماری بلندمدت‌تر نیاز دارد. در بررسی روش‌های مختلفی که از git استفاده می‌شود با تجربه افراد مختلفی آشنا شدم که شامل راهکارهایی بسیار کمال‌گرا (و غیر عملی) و یا راهکارهایی بسیار ابتدایی بودند.
یکی از بهترین روش‌هایی که به آن رسیدم مدلی است که یک برنامه‌نویس به نام Vincent Driessen بر اساس تجربه شخصیش به آن رسده و آن را بلاگش توضیح داده و در سال‌های اخیر توجه بسیاری را به خود جلب کرده.
در این روش مدل‌های مختلف branching برای سناریوهای زیر به زیبایی شرح داده شده‌است:
• Main Branch
• Feature Branch
• Release Branch
• Hotfix Branch
این مدل branching که اکنون به gitflow معروف است و در GitHub و BitBucket به عنوان یک روش مرسوم استفاده می‌شود و در مستندات آنها نیز می‌توانید این مدل را مطالعه کنید. در اینجا لینک مقاله اصلی معرفی می‌شود.

http://nvie.com/posts/a-successful-git-branching-model/

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

http://ow.ly/Iezl30jhTeJ

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

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


___

سوال هایی در مورد شی گرایی در سی شارپ

1. فیلد f را به صورت static و public در کلاس A تعریف کرده ایم. کلاس های B و C از کلاس A به ارث برده شده اند. آیا فیلد f به ازای کلاس های B و C، کپیِ مجزایی را خواهد داشت؟ در مورد کلاس های جنریک چطور؟
پاسخ:
https://stackoverflow.com/questions/5851497/static-fields-in-a-base-class-and-derived-classes

2. زمان اجرای constructor های static چه وقت می باشد؟
پاسخ:
https://stackoverflow.com/questions/1437352/when-is-a-static-constructor-called-in-c

3. چطور می توانیم، متدی تک پارامتری را تعریف کنیم که هر نوع ورودی ایی را بتواند بپذیرد و نوع پارامترِ متد از نوع object و یا dynamic نباشد.
پاسخ:
https://stackoverflow.com/questions/5886875/let-method-take-any-data-type-in-c-sharp

4. در دو کلاس A و B، متد M با نام و امضای یکسان تعریف شده است. این دو کلاس به طور کلی مجزا می باشند و از کلاس واحدی به ارث نرفته اند. چطور می توانیم در کلاس C متدی تعریف کنیم که با گرفتن یک نمونه از کلاس A و یا B، متد M را صدا بزند با این فرض که متدی که تعریف می کنیم فقط یک پارامتر دریافت کند و درون متد هم هیچ نوع Cast ایی صورت نگیرد. (Duck Typing)
پاسخ:
https://stackoverflow.com/questions/21278078/what-is-interface-duck-typing

5. چرا متد هایی که در یک کلاس virtual تعریف شده اند، نباید یکدیگر را صدا بزنند؟
پاسخ: وقتی متدی، متد دیگری را صدا می زند، یعنی متدِ اولی به متدِ دومی وابسته است. مشکل اینجاست که این وابستگی در پیاده سازی پنهان شده و قابل رویت نیست. در نتیجه اگر کسی در کلاسی که ارث بری شده، متد اول را override کند، هیچ گاه نخواهد فهمید که باید متدِ دوم را صدا بزند. در نتیجه در پیاده سازی جدید، بعد از صدا زدن متدِ اول در کلاس پیاده سازی شده، سیستم در وضعیت پایدار نخواهد بود.

6. کلاس PersonManager متدی تک پارامتری virtual به نام Manage دارد که یک Person را دریافت می کند. کلاس های EmployeeManager و StudentManager را چگونه از کلاس PersonManager ارث بری کنیم، که متد به ارث برده شده و override شده Manage در آن ها به جای پارامتر Person، نوع متناظر Employee و یا Student را دریافت کند.
پاسخ:
https://stackoverflow.com/questions/12593082/c-sharp-override-method-with-subclass-parameter

7. چرا متد های virtual نباید در constructor صدا زده شوند؟
پاسخ:
https://stackoverflow.com/questions/119506/virtual-member-call-in-a-constructor

چرا باید به Figma فرصت امتحان شدن بدهید

چند باری درباره ابزار جدید دیزاین اشتراکی (design-collaboration) به اسم Figma صحبت کردیم. تمامی ابزارها در ابتدای انتشار، در مقایسه با ابزارهای موجود، آنقدرها که باید کامل نیستند. باید به آنها زمان داد تا بهتر شوند و سپس آن‌ها به عنوان ابزار کار در نظر گرفت.
ابزار Figma با سرعتی بسیار خوب در حال پیشرفت و بروزرسانی‌ست. ما هم در تیم خود شروع به استفاده از این ابزار کردیم و برخی از مستندهای مربوط به دیزاین را در آن بصورت آنلاین و اشتراکی می‌سازیم.

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

این مقاله را از دست ندهید.

https://blog.figma.com/how-to-convince-your-team-to-switch-to-figma-921ca51c5f2a

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

#بررسی #ابزار #Figma
@Dexign فلسفه دیزاین

___‌

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

۱. من در استفاده از git بیسوادم، چون هنوز با طرز تفکر قدیمی خود از آن استفاده می‌کنم!

https://news.1rj.ru/str/SoftwarePhilosophy/1195

۲. سوال هایی در مورد شی گرایی در سی شارپ (Iran .Net)

https://news.1rj.ru/str/SoftwarePhilosophy/1196

۳. چرا باید به Figma فرصت امتحان شدن بدهید (فلسفه دیزاین)

https://news.1rj.ru/str/SoftwarePhilosophy/1197

ـــــــــــ

@SoftwarePhilosophy

مقایسه ایران با مایکروسافت ۱۰ سال پیش! تلگرام را فیلتر کنیم؟

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

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

از این لحاظ رویکرد ما خیلی شبیه مایکروسافت ۱۰ سال پیش است. مایکروسافتی که با دنیای open-source مخالف بود و سعی در نادیده گرفتن آن داشت تا جایی که به مرز حذف از بازار برنامه‌نویسی رسید. ولی آنها فهمیدند، خود را تغییر دادند، اوپن‌سورس بودن را درک کردند. به جای مقابله با آن شروع به استفاده از مزایای آن کردند و اکنون فعال‌ترین open-souce community در github هستند. و آرام آرام در حال بازگشت به بازار.

اگر تلگرام را تهدید می‌بینیم، به خاطر این است که «باز بودن« یا «open-source بودن» را تهدید می‌بینیم و باید به حال آن فکری کنیم. با فیلتر کردن ابزار، این طرز فکر از بین نمی‌رود، فقط تبدیل به حالت جنگجویانه‌ترش می‌شود و فیلتر کننده را از بین می‌برد.

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

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

نکته بعدی تکنولوژی blockchain است. قبل از آنکه باز هم دیر شود باید از الان روی آن کار کنیم. به جای اینکه از آن بترسیم باید آن را یاد بگیریم و از آن استفاده کنیم. من از آقای کورنگی، مدیرعامل MAPS متشکرم که سال پیش من را با این مفهوم آشنا کردند و باعث شدند مطالعاتی را در این زمینه شروع کنم. معتقدم باید از قدرت آینده‌بینی و آینده‌نگاری افرادی مثل ایشان نهایت استفاده را ببریم.

http://mehrandvd.me

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

http://ow.ly/wJ6i30jn1B4

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

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


___

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

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

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

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


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

___