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

آیا ترکیب WebAssembly و .Net آینده برنامه‌نویسی front-end است؟ این نام مقاله جدید اسکات هانسلمن است که در آن توضیح می‌دهد چطور .NET Core 2.0 این ایده را امکان پذیر کرده‌است که کدهای front-end را با c# نوشت و به WebAssembly کامپیال کرد. در این مقاله توضیح داده شده که چطور Steve Sanderson (برنامه نویس اصلی فریم‌ورک knockout) در یک پروژه آزمایشی به نام Blazor دقیقا مانند Angular, Knockout و Ember کد نوشته، با این تفاوت که این کد با C# نوشته شده.

مقاله زیر جزئیات نوشتن کد روی WebAssembly را با استفاده از .Net Core و C# شرح داده‌است.

https://www.hanselman.com/blog/NETAndWebAssemblyIsThisTheFutureOfTheFrontend.aspx

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

http://ow.ly/KVCh30ewRvs

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

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

___

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

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

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

پیشنهاد می‌کنم این مقاله جالب را همین حالا مطالعه کنید.

https://uxplanet.org/designing-for-human-memory-a2cdc0b6a75a

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

#بررسی #استراتژی #طراحی
@Dexign فلسفه دیزاین

____

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

در دنیای ورزش به اقدام افراد یک تیم برای تشکیل یک حلقه فشرده جهت مرور استراتژی، برنامه‌ریزی کوتاه‌مدت، انگیزه گیری و یا جشن، «هادل» (Huddle) گفته می‌شود.

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

این هادل‌ها به‌مرورزمان به نوعی عرف ورزشی تبدیل شده و دارای خصوصیات مشترکی شامل موارد زیر هستند:

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

https://goo.gl/mjFbDk

@IranAgile

یکی از دغدغه‌های همیشگی برنامه‌نویسان، تولید نرم‌افزار با سرعت بیشتر و کیفیت بالاتر می‌باشد. یکی از زبان‌های جدید پرطرفدار که به این امر کمک می کند F# است. با F# می‌توان بصورت Functional کد نوشت. تعداد خطوط نوشته شده در زبانهای Functional نسبت به سایر زبان‌ها کم می‌باشد. بطور مثال ۲۰ خط کد در C# با حدود ۵ خط کد در F# قابل بازنویسی است. ویدیو زیر به معرفی F# برای برنامه نویسان C# پرداخته است.

https://www.youtube.com/watch?v=KPa8Yw_Navk

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

http://ow.ly/KfWV30h1wUK

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

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

___

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

ممکن است در فرایند توسعه‌ی برنامه‌های SPA که UI‌ آن‌ها با screen‌های با اندازه‌های متفاوت موبایل تا دسکتاپ سازگار است٬ نیاز به تست برنامه روی Device ها داشته باشید. Browsersync ابزاری قدرتمند است که در ترکیب با Webpack و Hot Reloading این امکان را به شما می‌دهد تا به جای تست app روی شبیه ساز های device بتوانید مستقیما روی device تست و debug را انجام دهید.
برای توضیحات بیشتر به لینک زیر مراجعه کنید.

https://manavsehgal.com/browsersync-and-webpack-for-testing-web-apps-across-multiple-devices-64e7f7fa62f2


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

http://ow.ly/3dge30eCtwT

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


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

___

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

تبدیل کدهای C# به JavaScript در بسیاری از شرایط می‌توان مفید باشد. معمولا قسمت قابل توجهی از کدهای بین سرور و کلاینت که شبیه هم هستند می‌توانند در یک جا نوشته شوند. برای مثال مدل‌های انتقال اطلاعات DTO و یا Validation ها همه کدهایی هستند که پس از تعریف در سمت سرور می‌توانند در سمت کلاینت هم دوباره استفاده شوند.
هدف پروژه Bridge.NET اینجا امکان تبدیل کدهای C# به کدهای TypeScript و یا JavaScript است. در سایت این پروژه به صورت آنلاین می‌توانید آن را آزمایش کنید تا از نحوه کار آن مطلع شوید.

http://bridge.net/

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

http://ow.ly/yrVs30eL96Y

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


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

___

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

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

https://news.1rj.ru/str/SoftwarePhilosophy/1060

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

https://news.1rj.ru/str/SoftwarePhilosophy/1061

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

https://news.1rj.ru/str/SoftwarePhilosophy/1062

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

https://news.1rj.ru/str/SoftwarePhilosophy/1063
https://news.1rj.ru/str/SoftwarePhilosophy/1064

۵. آشنایی با Browsersync

https://news.1rj.ru/str/SoftwarePhilosophy/1066

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

https://news.1rj.ru/str/SoftwarePhilosophy/1068

ـــــــــــ

@SoftwarePhilosophy

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

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

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



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

http://ow.ly/GrJ430eStMy

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

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


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

___

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

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

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

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

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

http://ow.ly/4aX530f2OZz

#مهدی_بلوچی (http://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

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

http://ow.ly/jSR630f9rrn

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

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


___

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

۱. راهکارهایی برای افزایش سرعت Visual Studio https://news.1rj.ru/str/SoftwarePhilosophy/1071

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

https://news.1rj.ru/str/SoftwarePhilosophy/1073

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

https://news.1rj.ru/str/SoftwarePhilosophy/1074

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

https://news.1rj.ru/str/SoftwarePhilosophy/1076

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

https://news.1rj.ru/str/SoftwarePhilosophy/1078

ـــــــــــ

@SoftwarePhilosophy

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