#پست_مجدد این پست تا به حال بیش از ۱۹۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
برای 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 فلسفه دیزاین
هنری جاری، از سرچشمههای مراقبه
مدتها قبل طراحی دفترهای کار شرکتهای بزرگ تکنولوژی در اینترنت همهگیر شد و خیلی از ما این عکسها را دست به دست کرده و به دوستانمان نشان میدادیم و احتمالا حالا هم دلمان بخواهد در فضاهایی مشابه کار کنیم.بسیاری از شرکتهای سایر کشورها از جمله ایران هم همان رویکرد را در دیزاین محیط داخلی دفتر خود در نظر گرفتند.
از رویکردهای قدیمیتر میشود به فوتبالدستی و از رویکردهای جدیدتر به هماهنگی فضا و موضوع سرویسی که آن شرکت ارائه میدهد اشاره کرد. که البته تا امروز بخش اول، یعنی فوتبالدستی، اقبال بیشتری در ایران پیدا کرد.
امروز درباره یک دیزاینر فضاهای داخلی استارتاپها صحبت میکنیم، خانم 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 فلسفه دیزاین
____
مدتها قبل طراحی دفترهای کار شرکتهای بزرگ تکنولوژی در اینترنت همهگیر شد و خیلی از ما این عکسها را دست به دست کرده و به دوستانمان نشان میدادیم و احتمالا حالا هم دلمان بخواهد در فضاهایی مشابه کار کنیم.بسیاری از شرکتهای سایر کشورها از جمله ایران هم همان رویکرد را در دیزاین محیط داخلی دفتر خود در نظر گرفتند.
از رویکردهای قدیمیتر میشود به فوتبالدستی و از رویکردهای جدیدتر به هماهنگی فضا و موضوع سرویسی که آن شرکت ارائه میدهد اشاره کرد. که البته تا امروز بخش اول، یعنی فوتبالدستی، اقبال بیشتری در ایران پیدا کرد.
امروز درباره یک دیزاینر فضاهای داخلی استارتاپها صحبت میکنیم، خانم 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 فلسفه دیزاین
____
Medium
Zen and the Art of Designing Startups
How Kelly Robinson creates inspiring offices for the likes of Airbnb, Headspace, and SoundCloud.
Forwarded from Iran Agile
⭕ در جلسه مانفیست چابک چه گذشت؟
بعد از اینکه نرمافزاری ها تصمیم گرفتند خودشان سرنوشت این صنعت را در دست بگیرند، انقلاب چابکی شروع شد.
قبل از این مانفیست، جامعه نرمافزاری اعتقاد داشتند، که این صنعت به سمت درستی حرکت نمیکند. ایده اشتباه واترفال بشدت در حال گسترش بود.
اما نرمافزاری های کهنه کار روشهایی برای خودشان ایجاد کرده بودند که با نام متدهای سبک شناخته میشدند مثل اسکرام یا اکس پی. آنها تصمیم گرفتند یک اتحاد بین خود ایجاد کنند.
مارتین فاوولر و آنکل باب در کافی شاپی در شیکاگو با هم دیدار کردند و تصمیم گرفتند متن دعوت نامه را آماده کنند، مکانهای زیادی برای این جلسه کاندید شد ولی نهایتا اسنوبرد یوتا انتخاب شد، جایی سرد ولی بسیار جذاب در تاریخ نرمافزار.
۱۷ نفر افراد حاضر این جلسه، جزو اشخاص برجسته حوزه نرمافزار بودند، شخصی مانند کنت بک مربی فنی فیسبوک یا ...
این افراد در گروههای کوچک تقسیم شدند و نتایج را بر روی وایت برد مینوشتند، یک لحظه واردکانینگهام (خالق ویکی) همه را دعوت کرد جمع بندی مطالب را روی وایت برد نگاه کنند، پس از اینکه همه دور وایتبرد جمع شدند، خود او سریع بر روی صندلی پرید و از جمع عکس گرفت، و عکس معروف پشت زمینه مانیفست چابک خلق شد.
کانینگهام، علت عکس را تولد مانیفست بیان میکند. "احساس کردم لحظه تولد اتفاق بزرگی است"
بعد از اینکه ارزش ها و اصول ایجاد شدند، بدنبال اسم برای این مانیفست بودند. آنها با عنوان "سبک وزن" راحت نبود.
انتخاب اسم، فرآیند سختی بود، کلماتی مانند "آداپتیو" نیز روی میز بود، ولی کلمه "اجایل" انتخاب شد.
تنها نگرانی از سمت مارتین فاوولر بود که میگفت، تلفظ این کلمه در لهجه انگلستانی با آمریکایی متفاوت است "اجایل" و آمریکایی "اجیل".
آلیستر کوبورن، فضای این جلسه را بسیار دوستانه و عالی بیان کرده،
" همه دوست داشتند کمک کنند، به خوبی به هم گوش میدادیم، نقد میکردیم و ... ."
شوئبر میگوید " درست است که همه افراد جلسه مرد بودند، ولی از تعدادی خانم نیز دعوت شده بود که آنها حضور نداشتند."
بعد از اینکه جلسه تمام شد و همه محل را ترک کردند، مایکل بیدل، گفت که من اصلا فکر نمیکردم که بعدا این کار چقدر صدا خواهد کرد.
نسخه اولیه این بیانیه بر روی سایت agilemanifesto.org گذاشته شد، از سال ۲۰۱۶ امکان امضای این سند غیرفعال شد تا این بعنوان یک سند تاریخی در صنعت نرم افزار محفوظ شود.
ادامه داستان را در لینک زیر بخوانید:
https://goo.gl/7zCxzw
@iranagile
بعد از اینکه نرمافزاری ها تصمیم گرفتند خودشان سرنوشت این صنعت را در دست بگیرند، انقلاب چابکی شروع شد.
قبل از این مانفیست، جامعه نرمافزاری اعتقاد داشتند، که این صنعت به سمت درستی حرکت نمیکند. ایده اشتباه واترفال بشدت در حال گسترش بود.
اما نرمافزاری های کهنه کار روشهایی برای خودشان ایجاد کرده بودند که با نام متدهای سبک شناخته میشدند مثل اسکرام یا اکس پی. آنها تصمیم گرفتند یک اتحاد بین خود ایجاد کنند.
مارتین فاوولر و آنکل باب در کافی شاپی در شیکاگو با هم دیدار کردند و تصمیم گرفتند متن دعوت نامه را آماده کنند، مکانهای زیادی برای این جلسه کاندید شد ولی نهایتا اسنوبرد یوتا انتخاب شد، جایی سرد ولی بسیار جذاب در تاریخ نرمافزار.
۱۷ نفر افراد حاضر این جلسه، جزو اشخاص برجسته حوزه نرمافزار بودند، شخصی مانند کنت بک مربی فنی فیسبوک یا ...
این افراد در گروههای کوچک تقسیم شدند و نتایج را بر روی وایت برد مینوشتند، یک لحظه واردکانینگهام (خالق ویکی) همه را دعوت کرد جمع بندی مطالب را روی وایت برد نگاه کنند، پس از اینکه همه دور وایتبرد جمع شدند، خود او سریع بر روی صندلی پرید و از جمع عکس گرفت، و عکس معروف پشت زمینه مانیفست چابک خلق شد.
کانینگهام، علت عکس را تولد مانیفست بیان میکند. "احساس کردم لحظه تولد اتفاق بزرگی است"
بعد از اینکه ارزش ها و اصول ایجاد شدند، بدنبال اسم برای این مانیفست بودند. آنها با عنوان "سبک وزن" راحت نبود.
انتخاب اسم، فرآیند سختی بود، کلماتی مانند "آداپتیو" نیز روی میز بود، ولی کلمه "اجایل" انتخاب شد.
تنها نگرانی از سمت مارتین فاوولر بود که میگفت، تلفظ این کلمه در لهجه انگلستانی با آمریکایی متفاوت است "اجایل" و آمریکایی "اجیل".
آلیستر کوبورن، فضای این جلسه را بسیار دوستانه و عالی بیان کرده،
" همه دوست داشتند کمک کنند، به خوبی به هم گوش میدادیم، نقد میکردیم و ... ."
شوئبر میگوید " درست است که همه افراد جلسه مرد بودند، ولی از تعدادی خانم نیز دعوت شده بود که آنها حضور نداشتند."
بعد از اینکه جلسه تمام شد و همه محل را ترک کردند، مایکل بیدل، گفت که من اصلا فکر نمیکردم که بعدا این کار چقدر صدا خواهد کرد.
نسخه اولیه این بیانیه بر روی سایت agilemanifesto.org گذاشته شد، از سال ۲۰۱۶ امکان امضای این سند غیرفعال شد تا این بعنوان یک سند تاریخی در صنعت نرم افزار محفوظ شود.
ادامه داستان را در لینک زیر بخوانید:
https://goo.gl/7zCxzw
@iranagile
#پست_مجدد این پست تا به حال بیش از ۱۸۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
یکی از معماریهای نوین نرم افزاری که این روزها طرفداران زیادی را به خود جلب نموده است، معماری 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
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آشنایی با 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
۱. آشنایی با 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
Telegram
Software Philosophy
برای APIها و نرم افزارهایی که کاربران زیادی دارند Load Test امری حیاتی بشمار میآید. ابزارهای open source زیادی برای اینکار وجود دارند که Gatling یکی از آن ابزارها ست . Gatling ابزاری قدرتمند در زمینه Load test است که از پروتکل HTTP پشتیبانی می کند. با Gatling…
#پست_مجدد این پست تا به حال بیش از ۱۶۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
پایگاههای دادهای وجود دارند که مبنای آنها رویداد (Event) میباشد. دادهها در این پایگاههای داده، فقط قابل اضافه شدن میباشند و قابل حذف یا ویرایش نیستند. این امر باعث میشود تا اطلاعات ذخیره شده در این پایگاههای داده قابل اتکا و مطمئن باشند، زیرا تحت هیچ شرایطی حذف نمیشوند و یا تغییر نمیکنند. یکی از پایگاههای داده در این زمینه EventStore میباشد که با .NET نوشته شده است. از کاربردهای این نوع پایگاههای داده میتوان Event Sourcing و تحلیل رفتار کاربر را نام برد.
https://eventstore.org/docs/introduction/4.0.0/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/7rNP30fxL3o
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://eventstore.org/docs/introduction/4.0.0/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/7rNP30fxL3o
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
مدیریت خطا هنگام کار با Task در برنامههای Parallel یا Async بسیار حساس و گاهاً پیچیده است. در .Net 4.0 هنگام معرفی کتابخانه TPL نوع جدیدی از Exception به نام AggregateException معرفی شد تا بتواند حالتهای خطا در هنگام برنامهنویسی موازی را مدیریت کند.
از طرفی هنگام معرفی .Net 4.5 با انجام تغییراتی در ExceptionDispatchInfo امکان استفاده روش جدیدی در مدیریت خطا را ایجاد کرد.
مقاله زیر دلایل تاریخی و تصمیماتی که در نحوه ایجاد Exception ها در هنگام ایجاد خطا در حالتهای Parallel و Async گرفته شدهاست را شرح میدهد.
https://blogs.msdn.microsoft.com/pfxteam/2011/09/28/task-exception-handling-in-net-4-5/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/g2m930hpUbG
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
از طرفی هنگام معرفی .Net 4.5 با انجام تغییراتی در ExceptionDispatchInfo امکان استفاده روش جدیدی در مدیریت خطا را ایجاد کرد.
مقاله زیر دلایل تاریخی و تصمیماتی که در نحوه ایجاد Exception ها در هنگام ایجاد خطا در حالتهای Parallel و Async گرفته شدهاست را شرح میدهد.
https://blogs.msdn.microsoft.com/pfxteam/2011/09/28/task-exception-handling-in-net-4-5/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/g2m930hpUbG
#مهران_داودی (https://ow.ly/GwIl309lFEm)
کانال تلگرام:
@SoftwarePhilosophy
___
Parallel Programming with .NET
Task Exception Handling in .NET 4.5 | Parallel Programming with .NET
For the .NET Framework 4.5 Developer Preview, a lot of work has been done to improve the Task Parallel Library (TPL), in terms of functionality, in terms of performance, and in terms of integration with the rest of the .NET Framework.
Forwarded from Software Philosophy
اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرمافزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.
این پیغام را برای آنها Forward کنید.
#پست_مجدد این پست تا به حال بیش از ۳۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
تیم مفهومی است که هسته شکل گیری Agile و فریم ورکهایی چون Scrum است. Agile تنها مجموعهای از اصول نیست بلکه نوعی نگرش و تفکر است که برای پیاده سازی آن تک تک اعضای تیم باید زبان و فرایندهای آن را بیاموزند. پیاده سازی Agile مستلزم فرهنگ و روحیهی تیمی در هر مرحله است. مراحل گذار از سطوح ابتدایی Agile و رسیدن به یک تیم با کارایی بالا، در لینک زیر توضیح داده شده است.
https://www.scrumexpert.com/knowledge/5-steps-to-build-high-performance-agile-teams/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/VXyA30fDAin
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
https://www.scrumexpert.com/knowledge/5-steps-to-build-high-performance-agile-teams/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/VXyA30fDAin
#شراره_لطفی (https://ow.ly/xvC530dx8xL)
کانال تلگرام:
@SoftwarePhilosophy
___
Scrum Agile Project Management Expert
5 Steps to Build High Performance Agile Teams
The concept of team is at the heart of Agile software development and frameworks like Scrum. Forming high performance Agile teams is however not obvious. In this article, Debbie Madden suggests five steps that could bring your software development teams beyond…
#پست_مجدد این پست تا به حال بیش از ۱۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
امروزه میتوان از Entity Framework و نسخه Core آن در پروژههای مختلف با معماریهای مختلف مانند برنامههای تحت وب، برنامههای موبایل و ... استفاده نمود. اما عمده استفاده از آنها در برنامههای N-Tier مانند برنامههای دارای Rest Api در سمت سرور است که به کلاینت وب یا موبایل سرویس میدهند. با تغییر تنظیمات پیش فرض Entity Framework و کمی تغییر در سبک استفاده از آن، میتوان بسته به سناریو، آن قسمتی از سرعت برنامه را که مشخصا به Entity Framework مربوط است را بین سه تا صد برابر بهبود داد که عملا باعث میشود با همین سخت افزار موجود به تعداد کاربر بیشتری سرویس داده و سرعت کلی کار با برنامه را نیز بالاتر ببریم.
این مقاله ضمن ارائه مثال های عملی کمک میکند تا از Entity Framework در N-Tier app development استفاده مناسبتری داشته باشیم.
https://docs.bit-framework.com/docs/design-backgrounds/optimized-entity-framework-for-n-tier-apps.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/MKXr30fIX7X
#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)
کانال تلگرام:
@SoftwarePhilosophy
___
این مقاله ضمن ارائه مثال های عملی کمک میکند تا از Entity Framework در N-Tier app development استفاده مناسبتری داشته باشیم.
https://docs.bit-framework.com/docs/design-backgrounds/optimized-entity-framework-for-n-tier-apps.html
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/MKXr30fIX7X
#یاسر_مرادی (https://ow.ly/Ph6w30ebM21)
کانال تلگرام:
@SoftwarePhilosophy
___
#پست_مجدد این پست تا به حال بیش از ۲۲۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.
Forwarded from Software Philosophy
یکی از مشکلات برنامه نویسان پیاده سازی چندباره نرم افزار در چندین پلتفرم مختلف مانند وب، iOS و Android است که بسیار پر هزینه میباشد. با آمدن React Native، Xamarin و ... این امکان به وجود آمد که برای موبایلهای مختلف با یک کد مشترک نرم افزار ساخت. حال مایکروسافت پا را از این نیز فراتر گذاشته و با ایجاد فریمورک ReactXP بر روی React.JS و React Native بستری را فراهم نموده تا با نوشتن یک کد، آن نرم افزار همه جا از جمله در وب و کلیه موبایلها اجرا گردد.
https://microsoft.github.io/reactxp/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/iem730fSdfp
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
https://microsoft.github.io/reactxp/
⁉️ برای بحث و تبادل نظر فنی در مورد این پست، بر روی لینک زیر کلیک کنید:
https://ow.ly/iem730fSdfp
#علیرضا_وفی (https://ow.ly/Vna930dsUGr)
کانال تلگرام:
@SoftwarePhilosophy
___
microsoft.github.io
A library for building cross-platform apps - ReactXP
A library for cross-platform development
#خلاصه_مطالب «فلسفه نرمافزار» در هفته گذشته:
۱. آشنایی با پایگاه دادهی رویدادی EventStore
#database #eventsource
https://t.iss.one/SoftwarePhilosophy/1092
۲. دلایل تاریخی برای اتخاذ ایجاد Exception ها در هنگام ایجاد خطا در حالتهای Parallel و Async
https://t.iss.one/SoftwarePhilosophy/1093
۳. آشنایی با شیوه رسیدن به یک تیم Agile
#agile
https://t.iss.one/SoftwarePhilosophy/1096
۴. راهکارهایی برای استفاده بهتر از Entity Framework در N-Tier app development
https://t.iss.one/SoftwarePhilosophy/1098
۵. آشنایی با فریمورک ReactXP
https://t.iss.one/SoftwarePhilosophy/1100
ـــــــــــ
@SoftwarePhilosophy
۱. آشنایی با پایگاه دادهی رویدادی EventStore
#database #eventsource
https://t.iss.one/SoftwarePhilosophy/1092
۲. دلایل تاریخی برای اتخاذ ایجاد Exception ها در هنگام ایجاد خطا در حالتهای Parallel و Async
https://t.iss.one/SoftwarePhilosophy/1093
۳. آشنایی با شیوه رسیدن به یک تیم Agile
#agile
https://t.iss.one/SoftwarePhilosophy/1096
۴. راهکارهایی برای استفاده بهتر از Entity Framework در N-Tier app development
https://t.iss.one/SoftwarePhilosophy/1098
۵. آشنایی با فریمورک ReactXP
https://t.iss.one/SoftwarePhilosophy/1100
ـــــــــــ
@SoftwarePhilosophy
Forwarded from فلسفه دیزاین
چه کسی پیروز این مسابقه سرعت است؟
در وجود تمام ما دیزاینرها و شاید کل کسانی که کارهای خلاقانه انجام میدهند، چیزی هست که اجازه نمیدهد آرام بگیریم. هربار چیزی را میبینیم، حتی اگر آن چیز دارد درست کار میکند، علاقه داریم آن را بهتر کنیم.
صفحات بارگذاری یا Loading، همیشه حیاط خلوتی برای دیزاینرها بودهاند تا ایدههای خود را در آن تست کنند. اهمیت این امر از دو جهت است، اول اینکه دیزاینرها در صفحهای با کمترین پیچیدگی، ایده خود را پیاده کرده و دوم اینکه کاربر را برای حس نکردن زمان بارگذاری، جستجو و هر اتفاقی که در جریان است، کمک میکنند.
در همین راستا، مدتیست شرکتهایی مثل Facebook و Google دست به پیاده کردن مدلی از طراحی Loading زدند که به اسامی Non-Blocking UI، Progressive Loading و … معروف شد.
راستش را که بخواهید، از نظر من هم این دیزاین بسیار زیباتر و جذابتر از آن عناصر چرخان که قبلتر در Loadingها استفاده میشد، است. ولی این اتفاق همیشه هم خوب نیست. میپرسید چرا؟
پاسخ سادهست، به خاطره همین جذابیت کاربر با دقت و توجه بیشتری به صفحه نگاه کرده و حس میکند که زمان بارگذاری طولانیتر است. دلیل قرار دادن آینه در آسانسورها هم این است که ما سرگرم شده و کُندی سرعت رسیدن به طبقه مورد نظرمان را حس نکنیم، ولی در این Loadingهای جدید، یه حرکت خاص مدام تکرار شده و به خاطر جلب توجه، باعث کلافه شدن کاربر میشود.
در مقاله امروز، Kathryn Faulkner و Katherine Olvera، دو طراح تجربه کاربری، تستی را ترتیب دادهاند که بازخورد کاربران از حالتهای مختلف Loading را تست کنند.
نتایج جالب و قابل تامل است:
https://www.viget.com/articles/a-bone-to-pick-with-skeleton-screens
(زمان حدودی مطالعه، ۵ دقیقه)
#بررسی #چالش #Loading
@Dexign فلسفه دیزاین
____
در وجود تمام ما دیزاینرها و شاید کل کسانی که کارهای خلاقانه انجام میدهند، چیزی هست که اجازه نمیدهد آرام بگیریم. هربار چیزی را میبینیم، حتی اگر آن چیز دارد درست کار میکند، علاقه داریم آن را بهتر کنیم.
صفحات بارگذاری یا Loading، همیشه حیاط خلوتی برای دیزاینرها بودهاند تا ایدههای خود را در آن تست کنند. اهمیت این امر از دو جهت است، اول اینکه دیزاینرها در صفحهای با کمترین پیچیدگی، ایده خود را پیاده کرده و دوم اینکه کاربر را برای حس نکردن زمان بارگذاری، جستجو و هر اتفاقی که در جریان است، کمک میکنند.
در همین راستا، مدتیست شرکتهایی مثل Facebook و Google دست به پیاده کردن مدلی از طراحی Loading زدند که به اسامی Non-Blocking UI، Progressive Loading و … معروف شد.
راستش را که بخواهید، از نظر من هم این دیزاین بسیار زیباتر و جذابتر از آن عناصر چرخان که قبلتر در Loadingها استفاده میشد، است. ولی این اتفاق همیشه هم خوب نیست. میپرسید چرا؟
پاسخ سادهست، به خاطره همین جذابیت کاربر با دقت و توجه بیشتری به صفحه نگاه کرده و حس میکند که زمان بارگذاری طولانیتر است. دلیل قرار دادن آینه در آسانسورها هم این است که ما سرگرم شده و کُندی سرعت رسیدن به طبقه مورد نظرمان را حس نکنیم، ولی در این Loadingهای جدید، یه حرکت خاص مدام تکرار شده و به خاطر جلب توجه، باعث کلافه شدن کاربر میشود.
در مقاله امروز، Kathryn Faulkner و Katherine Olvera، دو طراح تجربه کاربری، تستی را ترتیب دادهاند که بازخورد کاربران از حالتهای مختلف Loading را تست کنند.
نتایج جالب و قابل تامل است:
https://www.viget.com/articles/a-bone-to-pick-with-skeleton-screens
(زمان حدودی مطالعه، ۵ دقیقه)
#بررسی #چالش #Loading
@Dexign فلسفه دیزاین
____
https://www.viget.com
A Bone to Pick with Skeleton Screens | Viget
Facebook and Google use skeleton screens to make their apps feel faster. Should you be using them too?
Forwarded from Iran Agile
⭕ آموزش با کیفیت مقدمهای برای پیاده سازی چابک
بسیاری از سازمانها بدون برنامهریزی خاصی شروع به پیاده سازی تفکر چابک میکنند و معمولا نتیجه آن استفاده ناقص از چارچوبی مثل اسکرام یا اکسپی خواهد بود و بالطبع بدبینی نسبت به این روشها و چارچوبها.
سه نکته مهم در مورد آموزش،
یک- مطمئن شوید همه در هر سطحی در این برنامههای آموزشی حضور داشته باشند.
اینکه نفرات مدیر هستند یا اینکه تجربه زیادی در مورد اسکرام دارند نباید بهانه عدم حضور آنها باشد. حضور مستمر، با تمرکز بالا و باعلاقه آنها ضروری است.
بیشتر این دوره برای ایجاد تعریف مشترک در بین افراد و به اشتراک گذاری تجربیات و صحبت در مورد موانع پیادهسازی است.
دو - مطمئن شوید فرد یا افراد آموزش دهنده خودشان چابک شده باشند، دانش کم میتواند بسیار خطرناک باشد. اگر ایده اشتباهی در ذهن افراد کاشته شود، پاک کردن آن بخاطر بدبینی یا ناامیدی افراد کار آسانی نخواهد بود.
سه - آموزش مدیران ارشد را جدی بگیرید، درک درست آنها از چابکی بسیار ضروری است. برخی از مدیران ارشد سازمانها و شرکتها هنوز فکر میکنند اجایل همان عجول بودن است.
https://goo.gl/KZMdba
@iranagile
بسیاری از سازمانها بدون برنامهریزی خاصی شروع به پیاده سازی تفکر چابک میکنند و معمولا نتیجه آن استفاده ناقص از چارچوبی مثل اسکرام یا اکسپی خواهد بود و بالطبع بدبینی نسبت به این روشها و چارچوبها.
سه نکته مهم در مورد آموزش،
یک- مطمئن شوید همه در هر سطحی در این برنامههای آموزشی حضور داشته باشند.
اینکه نفرات مدیر هستند یا اینکه تجربه زیادی در مورد اسکرام دارند نباید بهانه عدم حضور آنها باشد. حضور مستمر، با تمرکز بالا و باعلاقه آنها ضروری است.
بیشتر این دوره برای ایجاد تعریف مشترک در بین افراد و به اشتراک گذاری تجربیات و صحبت در مورد موانع پیادهسازی است.
دو - مطمئن شوید فرد یا افراد آموزش دهنده خودشان چابک شده باشند، دانش کم میتواند بسیار خطرناک باشد. اگر ایده اشتباهی در ذهن افراد کاشته شود، پاک کردن آن بخاطر بدبینی یا ناامیدی افراد کار آسانی نخواهد بود.
سه - آموزش مدیران ارشد را جدی بگیرید، درک درست آنها از چابکی بسیار ضروری است. برخی از مدیران ارشد سازمانها و شرکتها هنوز فکر میکنند اجایل همان عجول بودن است.
https://goo.gl/KZMdba
@iranagile
#پست_مجدد این پست تا به حال بیش از ۱۱۰۰ بار مشاهده شده و به نظر میرسد برای خوانندگان جدید کانال جذاب باشد.