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

۱. آیا ترکیب WebAssembly و .Net آینده برنامه‌نویسی front-end است؟

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

۲. دیزاین برای حافظه، دیزاین برای انسان‌ها

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

۳. اسکرام روزانه و «هادل»های ورزشی

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

۴. معرفی F# برای برنامه نویسان C#

https://t.iss.one/SoftwarePhilosophy/1063
https://t.iss.one/SoftwarePhilosophy/1064

۵. آشنایی با Browsersync

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

۶. تبدیل کدهای C# به JavaScript و پروژه Bridge.NET
#javascript #csharp #bridgenet #framework

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

ـــــــــــ

@SoftwarePhilosophy

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

در صورتی که از کندی Visual Studio رنج می‌برید و علاقه مند هستید سرعت کار ویژوال استدیو را بالاخص در زمان دیباگ و اجرای برنامه‌ها تا چندین برابر بهبود دهید، راهکارهای ارایه شده در این مقاله را که همگی تست شده اند و بعضا دارای PowerShell Script آماده به اجرا هستند استفاده کنید و از بهبود به دست آمده لذت ببرید.

https://docs.bit-framework.com/docs/good-to-know/visual-studio-speedup.html



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

https://ow.ly/GrJ430eStMy

#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)

✅ با سپاس از آقای سعید صالحی برای مشارکت در تهیه این مطلب
https://github.com/1saeedsalehi


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

___

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

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

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

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

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

https://ow.ly/4aX530f2OZz

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

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


___

کوله‌پشتی یک دیزاینر

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

در جستجوهایم به وب‌سایت Designer Lynx برخوردم. جایی که شاید ۸۰ درصد منابعی را که برای یادگیری معرفی می‌کنم، یکجا جمع کرده‌ست.
هیجان‌زده دست به صفحه‌کلید بُردم تا درباره‌ش برای شما بنویسم.
درست است که بخش‌های مختلف این وب‌سایت دست‌چینی هستند از بهترین منابع شروع دیزاین محصولات دیجیتال، ولی صرفا ابزارهای کوله‌پشتی شما به حساب می‌آیند. حتی وقتی شما بهترین‌ها را در کوله‌پشتی خود داشته باشید، اگر به کار نبندیدشان، فقط سنگینی آن‌ها را به دوش کشیده‌اید.

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

https://www.designerlynx.co/

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

____

🔴 داستان کاربری که به فنا رفت

چند روز قبل در شرکتی بودم که از من خواسته شده بود نحوه اجرای اسکرام اشان را بررسی کنم، از نحوه برگزاری برنامه ریزی اسپرینت پرسیدم، گفتند که این جلسه 20 دقیقه بیشتر طول نمی کشد، بچه ها موارد رو برمی دارند و همه توضیحات از قبل کامل نوشته شده است،

ما نیازمندی ها را در قالب داستان کاربری یا User Story در جیرا می‌نویسیم، بعلاوه سعی می کنیم همه توضیحات کامل باشد … مثلا “بعنوان کاربر من میخواهم …. تا بتوانم …..”، بعد پایین‌تر توضیحات رو مینویسیم، همه سناریوها و … .


زمانی که برای اولین بار “کنت بک”، ایده داستان کاربر را معرفی کرد، او از دست شرح نیازمندی شاکی بود، حتی او گفت که کلمه “نیازمندی” بزرگترین اشتباه تاریخی صنعت نرم افزار بوده است، زیرا این باعث ایجاد اجبار شده و یعنی شما نمی توانید نوع دیگری به مسئله نگاه کنید و اینکه رد و بدل کردن صرف مستندات باعث افزایش کج فهمی می شود. پس او پیشنهاد داد که به جای اینکه فقط مستندات شرح نیازمندی به من بدهی، به من بگو “داستان چیست؟”، داستان این کاربری که این را میخواهد چیست؟ او به دنبال چه چیزی است؟ نیاز اصلی اش چیست؟

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

“بعنوان __

من میخواهم _______

تا بتوانم ___________”

ما یاد گرفتیم از این به بعد به جای اینکه بنویسیم، “لاگین” بنویسیم “بعنوان کاربر، من میخواهم به سیستم لاگین کنم، تا بتوانم از امکانات سیستم استفاده کنم”.

مشکل الان از اینجا شروع می شود که، همان شرح نیازمندی، دوباره به اسم “داستان کاربری” مطرح شده اند، منتهی اولین جمله آنها یک قالب پیداکرده است.

🔴 مشکلاتی که دیده شد:

⏬ شرح نیازمندی دو ایراد اساسی داشت:

1- اجبار بود، یعنی همین رو میخواهیم , و قابل مذاکره نیست.
2- با توجه به دست به دست شدن،و اینکی توضیحی داده نمیشد، موجب ایجاد کج فهمی بود.

⏬ گفتگو گم شده است و همینی که هست

نیت اصلی پشت داستان کاربری، درک مشترک از نیاز کاربر بوده است، درک مشترک بالاتر از شرح نیازمندی.

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

گفتگو و توافق

بزرگترین کار یک مالک محصول این است،

1-مطمئن شود، که تیم نیاز واقعی کاربر یا مشتری را درک کرد باشند. (این با گفتگو و دیالوگ امکان پذیر است، مطمئن شوید که تیم سوال می پرسد)

2- بر روی شرایط با هم توافق کنند و توافق را حتما مکتوب کنند.

خلاصه،

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

https://goo.gl/QRbHvE

@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


___

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

۱. راهکارهایی برای افزایش سرعت Visual Studio https://t.iss.one/SoftwarePhilosophy/1071

۲. آشنایی با معماری میکروسرویس

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

۳. کوله‌پشتی یک دیزاینر (فلسفه دیزاین)

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

۴. داستان کاربری که به فنا رفت (Iran Agile)

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

۵. آشنایی با کتابخانه DistrubtedLock در .NET و مسئله تغییرات همزمان داده

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

ـــــــــــ

@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


___

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

یکی از معماری‌های نوین نرم افزاری که این روزها طرفداران زیادی را به خود جلب نموده است، معماری 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


___

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

برای 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


___

هنری جاری، از سرچشمه‌های مراقبه

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

امروز درباره یک دیزاینر فضاهای داخلی استارتاپ‌ها صحبت می‌کنیم، خانم Kelly Robinson. ایشان طراح داخلی شرکت‌هایی مثل Airbnb، SoundCloud و همچنین Headspace بوده‌اند. دیزاین‌های خانم Robinson به نوشتار خود مقاله، «ضدفضای کار» یا Anti-Office Space است. اعتقاد جالب ایشان این است که باید هر فضا، هر حسی را که لازم است به کاربر آن محیط بدهد.
«وقتی افراد حس کنند که فضای شرکت از حضور آن‌ها استقبال می‌کند، احساس راحتی بیشتری خواهند داشت و بیشتر خودشان خواهند بود.»

از بین همه این طراحی‌های داخلی، شرکت Headspace بیشترین جذابیت و هیجان را برای من داشت، چراکه راستش اصلا فکرش را نمی‌کردم انقدر شرکت بزرگی شده باشد.
خانم Robinson می‌گوید که جای تمرکز روی طراحی فضا، روی طراحی جریان انرژی تمرکز دارد. تکنیک‌های مختلف ایشان در این مقاله به اختصار آورده شده که اکثر آن‌ها متاثر از «مراقبه» یا meditation و «یوگا»ست.

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

https://magenta.as/zen-and-the-art-of-designing-startups-91b172de8d0a

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

پ. ن.
نمیدانم چرا بعضی از ما به جای «مراقبه» می‌گوییم meditation. به نظرم مراقبه کلمه بسیار زیباتری‌ست. اپلیکیشن بینظیر Headspace را برای مراقبه از دست ندهید.

#معرفی #نمونه_کار #طراح
@Dexign فلسفه دیزاین

____

⭕ در جلسه مانفیست چابک چه گذشت؟

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

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

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

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

۱۷ نفر افراد حاضر این جلسه، جزو اشخاص برجسته حوزه نرم‌افزار بودند، شخصی مانند کنت بک مربی فنی فیسبوک یا ...

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

کانینگهام، علت عکس را تولد مانیفست بیان میکند. "احساس کردم لحظه تولد اتفاق بزرگی است"

بعد از اینکه ارزش‌ ها و اصول ایجاد شدند، بدنبال اسم برای این مانیفست بودند. آنها با عنوان "سبک وزن" راحت نبود.

انتخاب اسم، فرآیند سختی بود، کلماتی مانند "آداپتیو" نیز روی میز بود، ولی کلمه "اجایل" انتخاب شد.

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

نسخه اولیه این بیانیه بر روی سایت agilemanifesto.org گذاشته شد، از سال ۲۰۱۶ امکان امضای این سند غیرفعال شد تا این بعنوان یک سند تاریخی در صنعت نرم افزار محفوظ شود.

ادامه داستان را در لینک زیر بخوانید:

https://goo.gl/7zCxzw

@iranagile

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

یکی از معماری‌های نوین نرم افزاری که این روزها طرفداران زیادی را به خود جلب نموده است، معماری 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


___

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

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

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

۲. آشنایی با Service Bus، MassTransit در معماری Microservices

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

۳. هنری جاری، از سرچشمه‌های مراقبه (فلسفه دیزاین)

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

۴. در جلسه مانفیست چابک چه گذشت؟ (Iran Agile)

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

ـــــــــــ

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

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

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

۲. آشنایی با Service Bus، MassTransit در معماری Microservices

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

۳. هنری جاری، از سرچشمه‌های مراقبه (فلسفه دیزاین)

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

۴. در جلسه مانفیست چابک چه گذشت؟ (Iran Agile)

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

ـــــــــــ

@SoftwarePhilosophy