#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. نوشتن کوئریهای 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
۱. نوشتن کوئریهای 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
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
مقایسه کد دو اسمبلی ساخته کاری است که در هنگام بررسی نسخههای مختلف یک 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://developer.telerik.com/topics/net/introducing-justassembly-lightweight-net-assembly-diff-tool/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/Mezs30c7VfS
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Telerik Developer Network
Introducing JustAssembly: A Lightweight .NET Assembly Diff Tool
John Bristowe goes over the features and use cases for JustAssembly, a new free and open source .NET assembly diff and analysis tool.
#پست_مجدد این پست تا به حال بیش از ۴۶۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
معماری نرمافزار مانند معماری ساختمان یک هنر است آیا تا به حال به فرق یک معمار و یک مهندس عمران فکر کردهاید؟ تمرکز مهندسان عمران معمولا بر ساخت سازهها است. آنها فکر میکنند چطور سازههایی مانند دیوار، در، پنجره و سایر اجزا را به طور صحیح بسازند. از طرف دیگر معمارها معمولا به اینها فکر نمیکنند! تمرکز اصلی آنها روی ساخت و معماری فضاهایی است که بین این اجزا به وجود میآید. در حقیقت مهندسین عمران به دیوارها فکر میکنند و معمارها به فضای بین دیوارها.
نکته جالب این است که انسانها یا مشتریان در نهایت از فضاها استفاده میکنند نه دیوارها! آنها پول خرج میکنند تا فضای زیبایی بخرند و به ندرت دیوارها را میبینند.
در مهندسی نرمافزار، ساخت دیوار مانند کد نویسی است. برنامهنویسان با کد نویسی در حقیقت در حال ساخت دیوارهایی هستند که این دیوارها مستقیما برای مشتری معنی ندارد. مشتریان امکاناتی را میبینند که توسط این کدها برای آنها خلق شدهاست. یکی از وظایف یک مهندس نرمافزار تمرکز بر فضاهای ایجاد شده برای مشتری است. اینکه این فضاها چقدر کارا و مفید طراحی شدهاند.
توضیحات کامل مفهوم فضا و تاثیر آن بر مشتری را میتوانید در لینک زیر بخوانید.
https://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/
#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
نکته جالب این است که انسانها یا مشتریان در نهایت از فضاها استفاده میکنند نه دیوارها! آنها پول خرج میکنند تا فضای زیبایی بخرند و به ندرت دیوارها را میبینند.
در مهندسی نرمافزار، ساخت دیوار مانند کد نویسی است. برنامهنویسان با کد نویسی در حقیقت در حال ساخت دیوارهایی هستند که این دیوارها مستقیما برای مشتری معنی ندارد. مشتریان امکاناتی را میبینند که توسط این کدها برای آنها خلق شدهاست. یکی از وظایف یک مهندس نرمافزار تمرکز بر فضاهای ایجاد شده برای مشتری است. اینکه این فضاها چقدر کارا و مفید طراحی شدهاند.
توضیحات کامل مفهوم فضا و تاثیر آن بر مشتری را میتوانید در لینک زیر بخوانید.
https://mehrandvd.me/2015/10/26/spaces-shape-your-software-architecture/
#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
Forwarded from فلسفه دیزاین (Ramin Khatibi)
قدرتهای 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 دیزاین
___
چندی قبل با تیم دیزاین روی طراحی یک بازی Trivia کار میکردیم. شاید بشود گفت که طراحی بازی همیشه یکی از چند لذت والای یک دیزاینر است. دیزاینر دوست دارد حتی اگر بازی اسم-فامیل را به شکل اپلیکیشن در میآورد، انیمیشنهایی در آن بگنجاند و از نظر بصری هیجانانگیزترین چیزی را که ممکن است، بسازد.
این موضوع برای تیم ما هم همینطور بود و برای هر بخش از این بازی Trivia که در حال طراحی آن بودیم انیمیشنهای هیجانانگیزی طراحی کردیم.
وقتی طراحیها به پایان رسید و نوبت به انتقال این انیمیشنها به تیم توسعه رسید، متوجه شدیم که صرفا با نمایش یک فایل MP4، نمیشود تکهها و جزئیات حرکتهای یک انیمیشن را به تیم توسعه منتقل کرد.
برای اینکه این انتقال به شکلی بهتر اتفاق بیافتد، تیم دیزاین ساعتهای زیادی را به مستند کردن انیمیشنهای هر بخش اختصاص داد که کاری بسیار وقتگیر بود.
علیرغم اینکه نتیجه کار تا حد خوبی راضیکننده بود ولی سختی مستندسازی، زمانبندی کار ما را بهم ریخت.
اخیرا به مقالهای از یکی طراحان تجربه کاربری در گوگل برخوردم که دقیقا مشکل مشابهی را داشتند و راه حل دیگری برای آن پیدا کردند. آقای Josh Fleetwood که در واقع راهبر تیم طراحی انیمیشنهای تجربه کاربری گوگل است، در این مقاله توضیح میهد که آنها انیمیشنهای خود را در After Effects میسازند و در انتقالشان به توسعهدهندگان با مشکل زیادی مواجه بودند. برای حل این مشکل دو افزونه (Plugin) بسیار کاربردی را به کار بستند که با استفاده از آنها میتوان خروجیهایی مستند از انیمیشنها به تیمهای توسعه ارائه داد و زندگی را شیرینتر کرد.
پیشنهاد میکنم این مقاله را از دست ندید، چرا که باعث صرفهجویی زیادی در زمان پروژه شما خواهد شد.
https://medium.com/google-design/bringing-sketch-and-after-effects-closer-together-d83b3e729c93
(زمان حدودی مطالعه، ۸ دقیقه)
#ابزار #افزونه #انیمیشن #تجربه_کاربری #motion
@Dexign دیزاین
___
Medium
Bringing Sketch and After Effects Closer Together
Introducing two new animation workflow tools from UX Motion Design at Google
#پست_مجدد این پست تا به حال بیش از ۴۶۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
افزونگی کد یک اشتباه برنامه نویسی نیست، یک بیماری معماری است. مهندسین نرمافزار همیشه تلاش میکنند تا «افزونگی کد» یا کدهای تکراری را کم کنند. در بسیاری از شرایط افزونگی کد به عنوان یک بیدقتی برنامهنویس محسوب میشود. برنامهنویسانی که به «نزدیکبینی کد» مبتلا هستند! یعنی در کدی که مینویسند گم میشوند و یادشان میرود که کجای کد هستند و چرا این کد را مینویسند و به طور کلی نمیتوانند دورنمایی از کاری را که انجام میدهند در ذهن خود تجسم کنند.
ولی تجربه نشان میدهد بیشترین علت «افزونگی کد» برنامهنویسان نیستند! بلکه این مشکل بیشتر به خاطر «معماری بد نرمافزار» است. معمار نرمافزار کسی است که هنگام معماری باید «فضاهای» کد را طوری معماری کند تا احتمال به خطا افتادن برنامهنویسان کمتر شود.
لینک زیر توضیح میدهد که چگونه یک معماری بد باعث «رشد افزونگی کد» در نرمافزار میشود.
https://mehrandvd.me/2016/02/28/growing-redundancy-an-architectural-disease/
#مهران_داودی
لینکداین:
https://ir.linkedin.com/in/mehrandvd
کانال تلگرام:
@SoftwarePhilosophy
___
ولی تجربه نشان میدهد بیشترین علت «افزونگی کد» برنامهنویسان نیستند! بلکه این مشکل بیشتر به خاطر «معماری بد نرمافزار» است. معمار نرمافزار کسی است که هنگام معماری باید «فضاهای» کد را طوری معماری کند تا احتمال به خطا افتادن برنامهنویسان کمتر شود.
لینک زیر توضیح میدهد که چگونه یک معماری بد باعث «رشد افزونگی کد» در نرمافزار میشود.
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
___
توضیحات بیشتر در لینک های زیر:
https://dzone.com/articles/api-load-testing-with-gatling
https://gatling.io/performancetesting /
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/obSH30firlJ
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
dzone.com
API Load Testing With Gatling - DZone Performance
A performance expert walks us through the use of two open source tools, Gatlin and JMeter, that allow you to perform load testing on your REST API endpoints
Forwarded from Iran Agile
🐘 استوری پوینت همان ساعت نیست
در پروژه های نرم افزاری روش های تخمین زدن متفاوتی وجود دارد؛ سادهترین روش این است از نفری که میخواهد کار را انجام بدهد بپرسید “این چند ساعت طول می کشد؟” و او بر اساس تجربه قبلی یک ساعتی را اعلام می کند. اما اکثر تیم های چابک از واحدی به نام استوری پوینت استفاده می کنند. تیم های جدید یا نفرات جدیدی که برای اولین بار سراغ این روش تخمین زدن میآیند دقیقا سعی میکنند ساعت را به پوینت ربط دهند یعنی هر پوینت معادل هشت ساعت.
علت اینکه ما از استوری پوینت استفاده می کنیم این است که می خواهیم به خرد جمعی مراجعه کنیم. یعنی آدم های مختلف در کنار هم بتوانند به صورت تعاملی در مورد اندازه یک کار نظر دهند. زمانی که شما پوینت را به ساعت نسبت می دهید بزرگترین قابلیت آن یعنی “نسبیت” را از بین می برید.
وقتی به یک کاری می گوییم سه پوینت، سه پوینت به تنهایی هیچ معنی ندارد، سه پوینت نسبت به چه چیز؟ در نسبیت شما همیشه باید یک پایه داشته باشید. مثلا اگر فرض کنیم یک صفحه Add/Edit ساده 8 پوینت است. پس سری بعد قرار باشد یک صفحه Add/Edit داشته باشیم که کمی نیز قوانین کسبکار در آن دخیل است، احتمالا پوینت 13 است.
🔴 چرا ساعت همان پوینت نیست؟
شاید یک صفحه Add/Edit برای من هشت ساعت طول بکشد، پس باید پوینت بشود 1 اما برای همکارم که کمی کند تر است، این کار دو روز طول می کشد پس این پوینت باید بشود 2. حالا فرض کنید این دونفر چگونه می خواهند در مورد اینکار با هم از روش پوینت استفاده کنند؟ اما اگر کل تیم، فرای اینکه چه کسی می خواهد این کار را انجام بدهد در نظر بگیرند که هر Add/Edit مثلا 8 پوینت است، پس همه تعریف مشترکی از پوینت خواهند داشت.
اما در غیر اینصورت بهتر است از لفظ پوینت استفاده نکنید.
🔴 آیا ما مجبور هستیم از پوینت استفاده کنیم؟
اصولا نه. اصلا نیازی به استفاده از این روش نیست. اکثر تیم ها در ایران به اسم از پوینت استفاده می کنند ولی همان سیستم ساعتی است.
بهترین حالت چه چیز است؟
بهترین حالت این است که شما User Story ها را از روش پوینت استفاده کنید، بدلیل اینکه همه تیم بر روی این کار تعامل داشته باشند. اما وقتی این User Story به چندین تسک شکست، آنها باید ساعتی تخمین زده شوند. چرا؟ چون قرار است تسک را یک نفر خاص انجام بدهد و آن نفر بر اساس مهارت ها و تجربیات قبلی آن کار را تخمین می زند.
@iranagile
🌐 https://goo.gl/7fQaxs
در پروژه های نرم افزاری روش های تخمین زدن متفاوتی وجود دارد؛ سادهترین روش این است از نفری که میخواهد کار را انجام بدهد بپرسید “این چند ساعت طول می کشد؟” و او بر اساس تجربه قبلی یک ساعتی را اعلام می کند. اما اکثر تیم های چابک از واحدی به نام استوری پوینت استفاده می کنند. تیم های جدید یا نفرات جدیدی که برای اولین بار سراغ این روش تخمین زدن میآیند دقیقا سعی میکنند ساعت را به پوینت ربط دهند یعنی هر پوینت معادل هشت ساعت.
علت اینکه ما از استوری پوینت استفاده می کنیم این است که می خواهیم به خرد جمعی مراجعه کنیم. یعنی آدم های مختلف در کنار هم بتوانند به صورت تعاملی در مورد اندازه یک کار نظر دهند. زمانی که شما پوینت را به ساعت نسبت می دهید بزرگترین قابلیت آن یعنی “نسبیت” را از بین می برید.
وقتی به یک کاری می گوییم سه پوینت، سه پوینت به تنهایی هیچ معنی ندارد، سه پوینت نسبت به چه چیز؟ در نسبیت شما همیشه باید یک پایه داشته باشید. مثلا اگر فرض کنیم یک صفحه 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
۱. ابزار اوپن سورس 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
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
امنیت یکی از دغدغههای مهم نرمافزارهای 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
___
یکی از مهمترین تعارضات تیمهای برنامهنویس با دپارتمانهای امنیت، این طرز تفکر است که امنیت «یک تست نهایی» است که باید در انتها انجام شود. این رویکرد اشتباه غالبا باعث میشود ریسکهای امنیتی زیادی متوجه سازمان شود. در تیمهای حرفهای امنیت یک کار روزانه است که همه هر روز در حال انجام آن هستند.
اخیرا دپارتمان امنیت «بهسازان» در بانک ملت پروژه جالبی را به نام «مسابقه CTF» یا Capture The Flag را اجرا کردهاست. طی این رویداد با برگزاری یک سری مسابقات جذاب برنامهنویسی امنیتی، به طور ناخودآگاه دانش امنیتی تمام افراد سازمان، مخصوصا برنامه نویسان بالا رفتهاست. نکته جالبه پلتفرم بهسازان این بود که آن را طوری طراحی کردهاند که میتوانند در اختیار سایر سازمانها نیز قرار دهند تا متناسب با بیزنس خود آن را پیکربندی کنند و موجب آموزش این مهارتها به سازمان خود شوند.
https://mehrandvd.me/2017/05/23/capture-flag-secure-software/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/p03w30cbHdO
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Dot Philosophy
Capture the Flag: Secure Software - Dot Philosophy
As a software consultant, I've involved in lots of projects and teams, working with lots of super energetic developers. But believe me, working on a startup project is totally different to a large scale project. One of the most important concerns in a large…
Forwarded from فلسفه دیزاین (Ramin Khatibi)
طراحی دکمهها در گذر زمان
دکمهها موجودات جالبی هستند. قبلتر هم مفصلا به آنها پرداخته بودیم. با دکمهها ما خرید خود را نهایی میکنیم، به حساب خود در اپلیکیشن موبایلبانکمان وارد میشویم، فرمهای ثبتنام را ثبت میکنیم و …
در مقاله امروز، آقای Wojciech Dobry نتیجه بررسی را که روی تغییرات طراحی ۸ ساله دکمهها داشتهاند، ارائه میدهند.
این تحقیق روی پلتفرم Dribbble اتفاق افتاده است.
پیشنهاد میکنم این سیرِ زمانی جالب را همین حالا روی این مقاله بررسی کنید:
https://www.toptal.com/designers/ui/button-design-dribbble-timeline
(زمان حدودی مطالعه، ۶ دقیقه)
#دکمه #تاریخچه #روند
@Dexign دیزاین
___
دکمهها موجودات جالبی هستند. قبلتر هم مفصلا به آنها پرداخته بودیم. با دکمهها ما خرید خود را نهایی میکنیم، به حساب خود در اپلیکیشن موبایلبانکمان وارد میشویم، فرمهای ثبتنام را ثبت میکنیم و …
در مقاله امروز، آقای Wojciech Dobry نتیجه بررسی را که روی تغییرات طراحی ۸ ساله دکمهها داشتهاند، ارائه میدهند.
این تحقیق روی پلتفرم Dribbble اتفاق افتاده است.
پیشنهاد میکنم این سیرِ زمانی جالب را همین حالا روی این مقاله بررسی کنید:
https://www.toptal.com/designers/ui/button-design-dribbble-timeline
(زمان حدودی مطالعه، ۶ دقیقه)
#دکمه #تاریخچه #روند
@Dexign دیزاین
___
Toptal Design Blog
Button Design Over the Years – The Dribbble Timeline | Toptal®
Digital design and UIs are evolving at an incredible pace and the styling of buttons along with it. The Dribbble Button Timeline shows us how button styles have developed over the past decade.
یکی از معماریهای نوین نرم افزاری که این روزها طرفداران زیادی را به خود جلب نموده است، معماری 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
___
https://masstransit-project.com/
https://github.com/MassTransit/MassTransit
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/p03w30cbHdO
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
masstransit.io
An open-source distributed application framework for .NET
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
استفاده از 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
___
https://www.simple-talk.com/dotnet/net-framework/high-performance-powershell-linq/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/bgOq30cm0iu
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Simple Talk
High Performance PowerShell with LINQ - Simple Talk
PowerShell is a scripting language, and like all scripting languages it struggles to perform well with rapid iterative processes such as aggregation. It isn't well-known that PowerShell can use LINQ for many of those tasks which would otherwise use iteration…
#پست_مجدد این پست تا به حال بیش از ۱۰۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
مقایسه تکنولوژیهای 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
___
به نظر این برنامهنویس، اگر برنامه نویس 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
___
Forwarded from Iran Agile
🔴 روش استوری مپینگ در عمل
همیشه وقتی در مورد اسکرام صحبت میکنیم، اولین فرض ما این است که تیم یک بکلاگ محصول دارد. ولی در مورد اینکه این بکلاگ از کجا آمده است و چگونه تولید میشود زیاد صحبت نشده است. یکی از بهترین روشهای ایجاد بکلاگ اولیه محصول Story Mapping است.
بکلاگ یک بعدی یا چند بعدی؟
در تعریف بکلاگ محصول داریم که بکلاگ یک لیست الویت بندی شده از نیازمندی ها است که قرار است بر اساس اولویت از بالا و در طول اسپرینت ها انجام شود. مثلا یک فایل اکسل را در نظر بگیرید که نیازمندیها پشت سر هم در یک فایل نوشته است.
بکلاگ فلت چندین ایراد اساسی دارد:
1. حس یک لیست بی پایان از کارها که هیچ وقت تمام نمی شود (لیست بابانوئل)
2. نداشتن یک تصویر کلی از کل پروژه یا محصول
3. از دست دادن دید Iterative – Incremental
4. اولویت بندی بکلاگ فلت در عمل خیلی سخت است
https://goo.gl/iUryqU
@iranagile
همیشه وقتی در مورد اسکرام صحبت میکنیم، اولین فرض ما این است که تیم یک بکلاگ محصول دارد. ولی در مورد اینکه این بکلاگ از کجا آمده است و چگونه تولید میشود زیاد صحبت نشده است. یکی از بهترین روشهای ایجاد بکلاگ اولیه محصول 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
۱. امنیت در سیستمهای 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
Telegram
Software Philosophy
امنیت یکی از دغدغههای مهم نرمافزارهای large scale است. این دغدغه نه تنها به خود نرمافزار بر میگردد، بلکه بیشتر به تیمهایی برمیگردد که در حال توسعه این سیستمها هستند. اینکه تیم برنامهنویسی بتواند یک ویژگی امنیتی مانند لاگین را بنویسد بسیار تفاوت دارد…