بسیاری از برنامه نویسان و طراحان نرم افزار خاطره خوشی از معماری سرویس‌گرا ندارند. این مسأله دلایل بسیاری دارد که از جمله آنها می توان به پیچیدگی‌های فراوان ESB (Enterprise Service Bus) ها اشاره کرد. معماری سرویس‌گرا تلاشی بود برای جلوگیری از مشکلاتی که معماری یکپارچه (Monolithic) به تیم و محصول تحمیل می‌کرد. هرچند معماری سرویس‌گرا اقبال خوبی از سمت سازمان‌ها و شرکت‌های بزرگ کسب کرد ولی عمر زیادی نداشت و امروز از توجه کمتری برخوردار است. از طرفی محصولات یکپارچه بزرگ سازمانی و مشکلاتشان همچنان وجود دارند.
میکرو سرویس مفهمومی است که سعی میکند با استفاده از تجربه معماری سرویس‌گرا نقص‌های آن را برطرف کرده و به کمک طراحان بیاید.
در معماری میکروسرویس سیستم به اجزاء کوچکتری تقسیم می‌شود که هرکدام به طور مستقل عمل می‌کنند و یک عمل خاص را به خوبی انجام می‌دهند. این میکروسرویس‌ها درکنار همدیگر همان کار یک نرم افزار یکپارچه را انجام خواهند داد، آن‌ها توانایی این را دارند که زندگی را برای طراحان ساده‌تر و زیباتر کنند!

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

https://www.nginx.com/blog/introduction-to-microservices/

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

https://ow.ly/4aX530f2OZz

#مهدی_بلوچی (https://ow.ly/5kxI30exl7k )

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


___

۱۰ موقعیتی که طراحان تجربه کاربری از آن متنفر هستند!

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

این جملات تکراری، خنده‌دار و البته تامل‌برانگیز، ‌در تمامی مشاغل وجود دارد. به همین بهانه، امروز مقاله‌ای را از John Saito، کسی که به قول خودش «کلمــات» را برای شرکت و سرویس معظم Dropbox دیزاین می‌کند، بررسی می‌کنیم. این مقاله از زاویه‌ای دیگر، به بررسی موقعیت‌ها و جملاتی می‌پردازد که طراحان تجربه کاربری، بخصوص Copy Writerها از آن متنفرند.

پیشنهاد می‌کنم همین حالا این نوشته کوتاه و لذت‌بخش را مطالعه کنید:

https://medium.com/@jsaito/10-things-ux-writers-hate-to-hear-a3d561a63ae8

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

#جملات #طراحی_محصول #Copy_Writer
@Dexign دیزاین

___

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

رعایت Coding Style در هنگام برنامه‌نویسی، تاثیر زیادی در کیفیت کد تولید شده می‌گذارد. اغلب برای زبان‌هایی مانند C#, Java و یا JavaScript قوانین زیادی برای استایل وجود دارد. این قوانین کمتر در مورد زبان‌هایی مانند SQL رایج است در حالی که رعایت آنها در چنین زبان‌هایی بسیار مهم است. مقاله جالب زیر یک سری از اصول Coding Style در زبان SQL را شرح داده‌است. خلاصه نکات این مقاله عبارتند از:
• Formatting SQL Code
• Functional Misuse
• Variables and Parameters
• Wonderful world of collations

https://www.simple-talk.com/sql/t-sql-programming/basics-good-t-sql-coding-style/

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

https://ow.ly/XSIA30c5GS3


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

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


___

از پروژه بعدی این اشتباه رو تکرار نمی کنم، ولی چرا باز تکرار می شود؟

چندین بارشده است بشنویم که کسی گفته در پروژه بعدی فلان اشتباه را دیگه انجام نمی‌دهم، ولی در پروژه بعدی اشتباه بدتری انجام داده است واقعاً مشکل کجا است چرا این یادگیری‌ها مانع اشتباهات بعدی نمی‌شوند؟

🔴 پروژه‌های نرم‌افزاری خطی نیستند

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

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

علت اینکه تجربیات دقیق ما در آینده به درد نمی‌خورند این است که:

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

🔴 راه چاره چیست؟

اگر قرار باشد تجربیات گذشته در آینده به درد نخورد پس چاره چیست؟ چه‌کار باید کرد؟

مدل فکر کردن را باید یاد گرفت نه اینکه یک ایده را عیناً پیاده‌سازی کرد

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

اینکه من قبلاً این کار رو کردم، خوب نبود و این سری باید این کار رو بکنیم چون حتماً جواب می‌گیریم، دلیل خوبی نیست.

بیرون از جعبه باید فکر کرد

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

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

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

🔴 در عدم قطعیت، بهترین انتخاب در کار نیست

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

بهبود مستمر کلید موفقیت

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

اما یادگیری‌های ما برای همان پروژه است و نه پروژه بعدی. پروژه بعدی یادگیری خودش را نیاز خواهد داشت.

اسپرینت ها به سبک ایرانی

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

نتیجه‌گیری

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

یکی از مسایل مهم در دنیای نرم افزار، مساله تغییرات همزمان داده و جلوگیری از آن است. در SQL Server با داشتن یک Transaction از نوع Isolated می‌توان از تغییر همزمان یک آیتم جلوگیری کرد. حال اگر فرآیندهای کاری در .NET پیاده سازی شوند و نرم افزار توزیع شده (دارای چند سرور) باشد، چگونه در کد می‌توان از تغییر همزمان جلوگیری نمود؟ کتابخانه DistrubtedLock در .NET به این امر می‌پردازد و اجازه می دهد تا با استفاده از مکانیزم‌های مختلف در .NET ، یک Lock بین چند سرور نرم افزار ایجاد نمود و از همزمانی جلوگیری نمود.

https://github.com/madelson/DistributedLock/tree/master/DistributedLock

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

https://ow.ly/jSR630f9rrn

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

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


___

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

۱. نوشتن کوئری‌های DELETE بهینه برای حجم دیتای زیاد
#sql #optimization
https://t.iss.one/SoftwarePhilosophy/936

۲. آشنایی با معماری میکروسرویس
#microservice #architecture
https://t.iss.one/SoftwarePhilosophy/937

۳. ده موقعیتی که طراحان تجربه کاربری از آن متنفر هستند! (دیزاین)
#design
https://t.iss.one/SoftwarePhilosophy/938

۴. اصول Coding Style در زبان SQL
#sql #cleancode
https://t.iss.one/SoftwarePhilosophy/940

۵. چرا یادگیری از اشتباهات گذشته مانع اشتباهات در پروژه‌های بعدی نمی‌شوند؟ (Iran Agile)
#agile
https://t.iss.one/SoftwarePhilosophy/941

۶. آشنایی با کتابخانه DistrubtedLock در .NET و مسئله تغییرات همزمان داده
#dotnet #library #concurrency
https://t.iss.one/SoftwarePhilosophy/942

ـــــــــــ

@SoftwarePhilosophy

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

مقایسه کد دو اسمبلی ساخته کاری است که در هنگام بررسی نسخه‌های مختلف یک dll بسیار پیش می‌آید. با ابزارهایی مانند Reflector یا dotPeek می‌توان محتوای یک اسمبلی را مشاهده کرد ولی مقایسه دو نسخه مختلف یک اسمبلی با این ابزارها بسیار سخت است. ابزار JustAssembly یک ابزار رایگان و اوپن‌سورس است که اخیرا توسط تیم Telerik توسعه داده شده و به خوبی به برنامه نویسان این امکان را می‌دهد که نسخه‌های مختلف یک اسمبلی را با یکدیگر مقایسه کنند.

https://developer.telerik.com/topics/net/introducing-justassembly-lightweight-net-assembly-diff-tool/

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

https://ow.ly/Mezs30c7VfS


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

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


___

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

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


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


___