همیشه هر چیز خوبی، می‌تواند بد استفاده شود و نتیجه عکس دهد. این قضیه در مورد تکنولوژی هم صادق است. مقاله زیر توضیح می‌دهد که چه عادت‌های اشتباهی هنگام کار با 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

___

درباره اعتماد و اعتماد سازی

چابکی بدون کار تیمی می لنگد و کار تیمی هم بدون اعتماد بین اعضای تیم وهمی بیش نیست. اما اعتماد چیست؟

اعتماد: نداشتن ترس از آسیب پذیر شدن در برابر دیگران.
بی اعتمادی: وقتی که برای انجام دادن کارها از جانب دیگران احساس امنیت نمیکنیم و بیم این داریم که در برابر ایشان آسیب پذیر شویم.

BRAVING
یک acronym است که اجزای تشکیل دهنده اعتماد را بیان می کند:

Boundaries (مرزها)
من مرزهای مشخص خود را دارم و تو هم مرزهای خود را . هر دوی ما به مرزهای یکدیگر احترام میگذاریم

Reliability (اطمینان)
همواره من همان کاری که میگویم را انجام میدهم. تو نیز همواره همان کاری که میگویی انجام میدهی

Accountability (پاسخگویی)
من تو را برای پاسخگویی نسبت به انجام دادن کارهایی که گفته ای انجام میدهی متعهد می دانم. تو نیز می توانی مرا برای پاسخگویی نسبت به کارهایی که گفته ام انجام میدهم متعهد بدانی

Vault (صندوق اسرار)
هرچه که با من در میان می گذاری را نزد خود نگه می دارم و من نیز انتظار دارم که تو با من و دیگران چنین باشی

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

Non-Judgment (بدون قضاوت)
تو میتوانی در کنار تلاش خود، از دیگران کمک بخواهی و من قضاوتت نمی کنم. من می توانم در کنار تلاش خود از دیگران کمک بخواهم و تو قضاوتم نمی کنی

Generosity (خیرخواهی)
تو در مورد گفتار، رفتار و نیات من، خیرخواهانه ترین مفروضات را داری و من نیز در مورد تو همین گونه هستم.


توضیحات بیشتر در لینک زیر:

https://goo.gl/g6XsP8

نظرسنجی سالانه Stackoverflow

هر سال وب سایت Stackoverflow نظرسنجی ایی را برگزار می کند تا وضعیت صنعت توسعه نرم افزار را روشن و مشخص سازد. امسال بیش از 100 هزار نفر در این نظر سنجی شرکت کرده بودند. ایران با داشتن 0.9% شرکت کنندگان رتبه 21 ام را داشت.

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

* پر استفاده ترین IDE در بین شرکت کنندگان Visual Studio Code و Visual Studio بوده اند. هر کدام سهمی تقریبا برابر با 35% داشته اند.

* نزدیک به 50% توسعه دهندگان از ماشین های ویندوزی استفاده می کنند. سیستم های مک و لینوکس هر کدام سهمی برابر با 25% دارند.

* کنترل نسخه GIT تقریبا همه رقیبان دیگر نظیر SVN و Team Foundation Version Control را منسوخ کرده و نزدیک به 90% افراد از گیت استفاده می کنند.

* برای اشتراک دانش و مدیریت تیم سیستم های Slack و Jira پر استفاده ترین هستند و تقریبا نیمی از شرکت کنندگان از این دو استفاده می کنند. با کمال تعجب سرویس های مایکروسافتی در این حوزه هیچ بُردی ندارند.

* محبوب ترین فریم ورک ها به ترتیب Angular و React و dotNet Core و سپس Java Spring می باشند.

* نزدیک به 50 درصد توسعه دهندگان در حال توسعه سیستمی برای استقرار در لینوکس هستند و نزدیک به 35 درصد برای پلتفرمی ویندوزی سیستم طراحی می کنند. پلتفرم بعدی اندروید با 20% می باشد.

* دیتابیس MySQL با نزدیک به 60% پیشتاز می باشد. سپس SQL Server با 42% محبوب ترین دیتابیس می باشد. جایگاه بعدی متعلق به PostgreSQL می باشد. فراموش نکنیم که دیتابیس های اول و سوم بر خلاف SQL Server رایگان هستند.

* دیتابیس درون حافظه ای Redis، محبوب ترین سیستم برای استفاده به عنوان Cache می باشد.

* زبان های برنامه نویسی به ترتیب محبوبیت Java و سپس Python و سپس C# و سپس PHP می باشند.

گزارش نشان از رشد فزاینده ای در حوزه های مرتبط با "DevOps" و همچنین "Machine Learning" و "Data Science" حکایت می کند. این پوزیشن ها دارای حقوق های بسیار بالا و تقاضای زیادی هستند. علت رشد محبوبیت بالای زبان پایتون که زبان اصلی یادگیری ماشین هست و سایر کتابخانه ها نظیر "TensorFlow" می تواند همین باشد. اهمیت این حوزه ها به قدری است که مدیریت گوگل در کانادا اذعان داشت تا 5 سال دیگر افراد ناآشنا با حوزه "یادگیری ماشین" همه مزیت رقابتی خود را از دست خواهند داد.

* مشاهده نظرسنجی:

https://insights.stackoverflow.com/survey/2018?utm_source=so-owned&utm_medium=meta&utm_campaign=dev-survey-2018-promotion#technology

سال نوی همگی مخاطبان ایران دات نت مبارک ❤

@irandotnet

ایده‌هایی از بازی شطرنج برای آموزش دیزاین

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

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

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

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

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

http://alistapart.com/article/the-king-vs-pawn-game-of-ui-design

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

پ. ن.
پیش‌تر هم درباره عناصر دیزاین به مثابه اتم‌های آن صحبت کرده‌ایم. اگر آن مقاله را نخوانده‌اید، پیشنهاد می‌کنم که آن را هم مطالعه کنید چراکه می‌تواند کامل کننده این موضوع باشد:
«درس‌هایی درباره «دکمه‌ها»، خالص‌ترین نماینده یک طراحی»
https://news.1rj.ru/str/Dexign/57

#متد #آموزش #دیزاین
@Dexign فلسفه دیزاین

___

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

ما به عنوان مهندسین نرم‌افزار عادت کردیم که نرم‌افزار بسازیم، در حقیقت به آن معتاد شده‌ایم. به خاطر همین موضو است که اغلب دوست نداریم به این فکر کنیم که تغییری که در نرم‌افزار می‌دهیم چطور باید در نسخه لایو اجرایی شود. خیلی وقت‌ها نرم‌افزار را به صورت بسیار عالی تغییر می‌دهیم، ولی برنامه‌ای برای اینکه این تغییر چطور باید در نسخه‌اجرایی اعمال شود نداریم.
یکی از دغدغه‌ اصلی یک مهندس نرم‌افزار خوب، تمرکز بر Software Migration است. هر قطعه کدی که توسط یک مهندس نرم‌افزار نوشته می‌شود باید با دید یک Change دیده شود که باید روی نسخه لایو اعمال شود، نه صرفا یک کد جدید که Create شده‌است.

http://mehrandvd.me/2015/09/06/be-a-developer-not-a-programmer/


@SoftwarePhilosophy


___

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

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

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

۲. آیا تکنولوژی یا زبان برنامه‌نویسی در موفقیت یا شکست پروژه‌های نرم‌افزاری تاثیری دارند؟

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

۳. درباره اعتماد و اعتماد سازی (Iran Agile)

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

۴. نظرسنجی سالانه Stackoverflow (Iran .Net)

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

۵. ایده‌هایی از بازی شطرنج برای آموزش دیزاین (فلسفه دیزاین)

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

۶. اهمیت Software Migration و نوع نگاه در زمان تولید نرم‌افزار

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

ـــــــــــ

@SoftwarePhilosophy

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

یکی از دغدغه‌های همیشگی برنامه‌نویسان، تولید نرم‌افزار با سرعت بیشتر و کیفیت بالاتر می‌باشد. یکی از زبان‌های جدید پرطرفدار که به این امر کمک می کند F# است. با F# می‌توان بصورت Functional کد نوشت. تعداد خطوط نوشته شده در زبانهای Functional نسبت به سایر زبان‌ها کم می‌باشد. بطور مثال ۲۰ خط کد در C# با حدود ۵ خط کد در F# قابل بازنویسی است. ویدیو زیر به معرفی F# برای برنامه نویسان C# پرداخته است.

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

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

http://ow.ly/KfWV30h1wUK

#علیرضا_وفی (http://ow.ly/Vna930dsUGr)

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

___