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

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


https://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/

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


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


___

قدرت‌های Sketch و After Effects به کمک هم می‌آیند

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

اخیرا به مقاله‌ای از یکی طراحان تجربه کاربری در گوگل برخوردم که دقیقا مشکل مشابهی را داشتند و راه حل دیگری برای آن پیدا کردند. آقای Josh Fleetwood که در واقع راهبر تیم طراحی انیمیشن‌های تجربه کاربری گوگل است، در این مقاله توضیح می‌هد که آن‌ها انیمیشن‌های خود را در After Effects می‌سازند و در انتقال‌شان به توسعه‌دهندگان با مشکل زیادی مواجه بودند. برای حل این مشکل دو افزونه (Plugin) بسیار کاربردی را به کار بستند که با استفاده از آن‌ها می‌توان خروجی‌هایی مستند از انیمیشن‌ها به تیم‌های توسعه ارائه داد و زندگی را شیرین‌تر کرد.

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

https://medium.com/google-design/bringing-sketch-and-after-effects-closer-together-d83b3e729c93

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

#ابزار #افزونه #انیمیشن #تجربه_کاربری #motion
@Dexign دیزاین

___

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

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

ولی تجربه نشان می‌دهد بیشترین علت «افزونگی کد» برنامه‌نویسان نیستند! بلکه این مشکل بیشتر به خاطر «معماری بد نرم‌افزار» است. معمار نرم‌افزار کسی است که هنگام معماری باید «فضاهای» کد را طوری معماری کند تا احتمال به خطا افتادن برنامه‌نویسان کمتر شود.

لینک زیر توضیح می‌دهد که چگونه یک معماری بد باعث «رشد افزونگی کد» در نرم‌افزار می‌شود.


https://mehrandvd.me/2016/02/28/growing-redundancy-an-architectural-disease/

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


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


___

برای APIها و نرم افزارهایی که کاربران زیادی دارند Load Test امری حیاتی بشمار می‌آید. ابزارهای open source زیادی برای اینکار وجود دارند که Gatling یکی از آن ابزارها ست . Gatling ابزاری قدرتمند در زمینه Load test است که از پروتکل HTTP پشتیبانی می کند. با Gatling تنها با استفاده از تعداد اندکی دستگاه می‌توانید صدها هزار درخواست در ثانیه را روی Web application خود شبیه سازی کنید و گزارش و تحلیل‌هایی با پارامترهای دقیق بدست بیاورید. از نکات جذاب Gatling امکان تعریف سناریو تست کارایی به همان صورتی که در سایر فریمورک‌های تست اتوماتیک فراهم شده، می‌باشد. بدین ترتیب می توان این تست را هم در فرایند تست خودکار گنجاند.
توضیحات بیشتر در لینک های زیر:

https://dzone.com/articles/api-load-testing-with-gatling

https://gatling.io/performancetesting /

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

https://ow.ly/obSH30firlJ

#شراره_لطفی (https://ow.ly/xvC530dx8xL)

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


___

🐘 استوری پوینت همان ساعت نیست

در پروژه های نرم افزاری روش های تخمین زدن متفاوتی وجود دارد؛ ساده‌ترین روش این است از نفری که میخواهد کار را انجام بدهد بپرسید “این چند ساعت طول می کشد؟” و او بر اساس تجربه قبلی یک ساعتی را اعلام می کند.  اما اکثر تیم های چابک از واحدی به نام استوری پوینت استفاده می کنند. تیم های جدید یا نفرات جدیدی که برای اولین بار سراغ این روش تخمین زدن می‌آیند دقیقا سعی می‌کنند ساعت را به پوینت ربط دهند یعنی هر پوینت معادل هشت ساعت.

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

وقتی به یک کاری می گوییم سه پوینت، سه پوینت به تنهایی هیچ معنی ندارد، سه پوینت نسبت به چه چیز؟ در نسبیت شما همیشه باید یک پایه داشته باشید. مثلا اگر فرض کنیم یک صفحه Add/Edit ساده 8 پوینت است. پس سری بعد  قرار باشد  یک صفحه Add/Edit  داشته باشیم که کمی نیز قوانین کسب‌کار در آن دخیل است، احتمالا پوینت 13 است.

🔴 چرا ساعت همان پوینت نیست؟

شاید یک صفحه Add/Edit برای من هشت ساعت طول بکشد، پس باید پوینت بشود 1 اما برای همکارم که کمی کند تر است، این کار دو روز طول می کشد پس این پوینت باید بشود 2. حالا فرض کنید این دونفر چگونه می خواهند در مورد اینکار با هم از روش پوینت استفاده کنند؟ اما اگر کل تیم، فرای اینکه چه کسی می خواهد این کار را انجام بدهد در نظر بگیرند که هر  Add/Edit مثلا 8 پوینت است، پس همه تعریف مشترکی از پوینت خواهند داشت.

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

🔴 آیا ما مجبور هستیم از پوینت استفاده کنیم؟

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

بهترین حالت چه چیز است؟

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

@iranagile

🌐 https://goo.gl/7fQaxs

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

۱. ابزار اوپن سورس JustAssembly برای مقایسه نسخه‌های مختلف یک اسمبلی

https://t.iss.one/SoftwarePhilosophy/945

۲. مفهوم فضا و تاثیر آن بر مشتری

https://t.iss.one/SoftwarePhilosophy/947

۳. قدرت‌های Sketch و After Effects به کمک هم می‌آیند (دیزاین)

https://t.iss.one/SoftwarePhilosophy/948

۴. چگونه یک معماری بد باعث «رشد افزونگی کد» در نرم‌افزار می‌شود

https://t.iss.one/SoftwarePhilosophy/950

۵. آشنایی با Gatling ابزاری قدرتمند برای Load test

https://t.iss.one/SoftwarePhilosophy/951

۶. استوری پوینت همان ساعت نیست (Iran Agile)

https://t.iss.one/SoftwarePhilosophy/952

ـــــــــــ

@SoftwarePhilosophy

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

امنیت یکی از دغدغه‌های مهم نرم‌افزارهای large scale است. این دغدغه نه تنها به خود نرم‌افزار بر می‌گردد، بلکه بیشتر به تیم‌هایی برمی‌گردد که در حال توسعه این سیستم‌ها هستند. اینکه تیم برنامه‌نویسی بتواند یک ویژگی امنیتی مانند لاگین را بنویسد بسیار تفاوت دارد با اینکه بتواند یک کد را امن بنویسد. «توانایی کد نویسی امن» یک مهارت است که مخصوصا برنامه‌نویسان سیستم‌های large scale مانند سیستم‌های بانکی یا ERP باید از آن برخوردار باشند.
یکی از مهمترین تعارضات تیم‌های برنامه‌نویس با دپارتمان‌های امنیت، این طرز تفکر است که امنیت «یک تست نهایی» است که باید در انتها انجام شود. این رویکرد اشتباه غالبا باعث می‌شود ریسک‌های امنیتی زیادی متوجه سازمان شود. در تیم‌های حرفه‌ای امنیت یک کار روزانه است که همه هر روز در حال انجام آن هستند.
اخیرا دپارتمان امنیت «بهسازان» در بانک ملت پروژه جالبی را به نام «مسابقه CTF» یا Capture The Flag را اجرا کرده‌است. طی این رویداد با برگزاری یک سری مسابقات جذاب برنامه‌نویسی امنیتی، به طور ناخودآگاه دانش امنیتی تمام افراد سازمان، مخصوصا برنامه نویسان بالا رفته‌است. نکته جالبه پلتفرم بهسازان این بود که آن را طوری طراحی کرده‌اند که می‌توانند در اختیار سایر سازمان‌ها نیز قرار دهند تا متناسب با بیزنس خود آن را پیکربندی کنند و موجب آموزش این مهارت‌ها به سازمان خود شوند.

https://mehrandvd.me/2017/05/23/capture-flag-secure-software/

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

https://ow.ly/p03w30cbHdO

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

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


___

طراحی دکمه‌ها در گذر زمان

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

در مقاله امروز، آقای Wojciech Dobry نتیجه بررسی را که روی تغییرات طراحی ۸ ساله دکمه‌ها داشته‌اند، ارائه می‌دهند.
این تحقیق روی پلتفرم Dribbble اتفاق افتاده است.

پیشنهاد میکنم این سیرِ زمانی جالب را همین حالا روی این مقاله بررسی کنید:

https://www.toptal.com/designers/ui/button-design-dribbble-timeline

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

#دکمه #تاریخچه #روند
@Dexign دیزاین

___

یکی از معماری‌های نوین نرم افزاری که این روزها طرفداران زیادی را به خود جلب نموده است، معماری Microservices می‌باشد. این معماری با پیاده سازی سرویس‌های متعدد و غیروابسته، پیاده‌سازی تغییرات در نرم افزار را ساده‌تر می نمایند. در این معماری Microservice ها به دو شکل متداول با هم ارتباط دارند، یکی از طریق REST و دیگری از طریق Messaging. پیاده سازی بصورت Messaging از بهم تنیدگی کدها می‌کاهد و وابستگی بین سرویس‌ها را به حداقل می‌رساند. برای این نوع پیاده سازی در .NET می توان از کتابخانه MassTransit استفاده نمود. MassTransit یک Service Bus می‌باشد که از تکنولوژی‌های RabbitMQ و Azure ServiceBus در پشت صحنه بهره می‌برد و کمک می‌کند تا بتوان راحت‌تر معماری Microservice را بطور صحیح پیاده سازی نمود.


https://masstransit-project.com/

https://github.com/MassTransit/MassTransit



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

https://ow.ly/p03w30cbHdO

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

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


___

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

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

https://www.simple-talk.com/dotnet/net-framework/high-performance-powershell-linq/

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

https://ow.ly/bgOq30cm0iu


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

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


___

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

مقایسه تکنولوژی‌های React Native و Xamarin Forms برای پروژه‌های Cross Platform یکی از بحث‌های داغ این روز‌های برنامه‌نویسان موبایل است. مقاله زیر این دو فریم‌ورک را از ابعاد مختلف مقایسه کرده و نظر خود را در هر مورد شرح داده. نکته جالب این مقاله این است که قبل از توضیح کامل، در یک پاراگراف که آن را Short Version یا نسخه کوتاه نام‌گذاری کرده خیلی خلاصه نتیجه را توضیح داده‌است.
به نظر این برنامه‌نویس، اگر برنامه نویس JavaScript هستید React Native را انتخاب خواهید کرد، اگر برنامه‌نویس C# باشید Xamarin Forms را انتخاب خواهید کرد. اگر به هر دو مسلط باشید (که معمولا کم پیش می‌آید) برای پروژه‌های واقعی و بیزنسی Xamarin Forms را انتخاب می‌کنید و React Native را برای پروژه‌های شخصی انتخاب خواهید کرد.

https://shellmonger.com/2017/05/25/which-is-better-react-native-or-xamarin-forms/


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

https://ow.ly/9ZTM30cuKFN


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

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


___

🔴 روش استوری مپینگ در عمل

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

بک‌لاگ یک بعدی یا چند بعدی؟

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

بک‌لاگ فلت چندین ایراد اساسی دارد:

1. حس یک لیست بی پایان از کارها که هیچ وقت تمام نمی شود (لیست بابانوئل)
2. نداشتن یک تصویر کلی از کل پروژه یا محصول
3. از دست دادن دید Iterative – Incremental
4. اولویت بندی بک‌لاگ فلت در عمل خیلی سخت است

https://goo.gl/iUryqU

@iranagile

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

۱. امنیت در سیستم‌های large scale با راهکار تیم امنیت بهسازان بانک ملت
#security #ctf
https://t.iss.one/SoftwarePhilosophy/955

۲. طراحی دکمه‌ها در گذر زمان (دیزاین)
#design #ux
https://t.iss.one/SoftwarePhilosophy/956

۳. آشنایی با Service Bus، MassTransit در معماری Microservices
#architecture #microservice
https://t.iss.one/SoftwarePhilosophy/957

۴. استفاده از LINQ در PowerShell
#powershell #linq
https://t.iss.one/SoftwarePhilosophy/959

۵. مقایسه تکنولوژی‌های React Native و Xamarin Forms برای پروژه‌های Cross Platform
#crossplatform #ReactNative #Xamarin
https://t.iss.one/SoftwarePhilosophy/961

۶. روش استوری مپینگ در عمل (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/962

ـــــــــــ

@SoftwarePhilosophy

پایگاه‌های داده‌ای وجود دارند که مبنای آنها رویداد (Event) می‌باشد. داده‌ها در این پایگاه‌های داده، فقط قابل اضافه شدن می‌باشند و قابل حذف یا ویرایش نیستند. این امر باعث می‌شود تا اطلاعات ذخیره شده در این پایگاه‌های داده قابل اتکا و مطمئن باشند، زیرا تحت هیچ شرایطی حذف نمی‌شوند و یا تغییر نمی‌کنند. یکی از پایگاه‌های داده در این زمینه EventStore می‌باشد که با .NET نوشته شده است. از کاربردهای این نوع پایگاه‌های داده می‌توان Event Sourcing و تحلیل رفتار کاربر را نام برد.

https://eventstore.org/docs/introduction/4.0.0/

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

https://ow.ly/7rNP30fxL3o

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

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


___

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

مدیریت خطا یا Exception Handling صحیح یکی از نکات مهم در کدهای با کیفیت است. در یک کد با کیفیت باید به خطاها فکر کرد و برای آنها در هنگام توسعه تصمیم گرفت. اینکه کجا یک exception را catch کنید و کجا به آن اجازه دهید به لایه‌های بالاتر رود، اینکه چگونه exception‌ ها را در هم wrap کنید و موارد بسیار دیگر مستقیما روی کیفیت کد شما تاثیر می‌گذارد.
مقاله زیر در مورد نحوه انجام این کار در Large .NET Projects را شرح داده‌است و مطالعه آن می‌تواند کمک زیادی به بالا رفتن کد برنامه نویسان کند.

https://www.dotnetcurry.com/patterns-practices/1364/error-handling-dotnet-projects

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

https://ow.ly/SWJZ30cAalk


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

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


___