تاکنون اتصال به دستگاه‌های بلوتوث تنها از طریق native apps امکان پذیر بود. Web Bluetooth API این امکان را برای web browser ها نیز فراهم آورده است. کتابخانه‌هایی برای کار با این API‌ ها در Node‌و Angular و Polymer نیز پیاده‌سازی شده است. لینک زیر توضیحاتی در مورد این API ها و کاربری آن ارايه می‌دهد.

https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web

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

http://ow.ly/6Gq530efr9v

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

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

___

از مسایل مهم در هر نرم افزار وب، علاوه بر زیرساخت‌های شبکه و سیستم عامل، ایمن‌سازی نرم افزار می‌باشد. NWebSec یک کتابخانه مبتنی بر .NET می‌باشد که قابل استفاده در ASP.NET و ASP.NET Core نیز بوده و با استفاده از Security Headers و سایر روش‌ها به امنیت بیشتر نرم افزارها کمک می‌کند.

https://docs.nwebsec.com/en/latest/nwebsec/getting-started.html

http://www.dotnetnoob.com/2012/09/security-through-http-response-headers.html

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

http://ow.ly/umRg30ehqWV


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

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

___

کارایی و سرعت EntityFramework از گذشته تا به امروز از معضلاتی است که در پروژه‌ها با آن مواجه می‌شویم. همه‌ی راحتی و سرعتی که در زمان توسعه نرم افزار با استفاده از EF CodeFirst به دست می‌آوریم کمابیش برای بهبود سرعت اجرای queryهای وحشتناکی که بعضا توسط EF تولید می‌شود صرف می‌کنیم. ابزارهایی از قبیل Rhino Entity Framework Profiler و LINQ Pad در این راه یاری رسان بوده‌اند.اما ZZZ Projects راه حل بهتری ارایه داده‌اند. آن‌ها کتابخانه‌هایی روی EF ارايه داده‌اند که امکان عملیات CRUD و Merge بصورت batch با سرعت بالا را فراهم می‌آورند. همچنین امکان به روز رسانی بدون بارگزاری موجودیت‌ها از دیتابیس و ارسال چند Query بصورت batch به دیتابیس و بسیاری امکانات دیگر که در لینکهای زیر توضیحات آن آمده است.

http://www.zzzprojects.com/

http://entityframework-extensions.net/

http://entityframework-plus.net/
همچنین از دیگر محدودیت های EF Codefirst عدم امکان استفاده از SQL Function ها و Stored Procedure هایی با خروجی‌های متفاوت است. لینک زیر کتابخانه EntityFramework.Functions را معرفی می‌کند که به کمک آن با این محدودیت EF Codefirst خداحافظی می‌کنید.

https://weblogs.asp.net/Dixin/EntityFramework.Functions

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

http://ow.ly/3nz630ejcU6

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

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

___

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

۱. مزایای Server Sent Events برای پروژه‌های تحت وب
#dotnet #web
https://news.1rj.ru/str/SoftwarePhilosophy/895

۲. ایجاد هدر برای وبسایت‌های چند صفحه‌ای به منظور سرعت بخشی به لود شدن صفحات
#web
https://news.1rj.ru/str/SoftwarePhilosophy/896

۳. آشنایی با Code Map در Visual Studio
#visualstudio
https://news.1rj.ru/str/SoftwarePhilosophy/897

۴. اتصال به دستگاه‌های بلوتوث از طریق web browser به وسلیه Web Bluetooth API
#web #bluetooth
https://news.1rj.ru/str/SoftwarePhilosophy/898

۵. ایمن‌سازی نرم افزار در دات نت به وسیله کتابخانه NWebSec
#security #dotnet
https://news.1rj.ru/str/SoftwarePhilosophy/899

۶. چند راه حل برای افزایش کارایی و سرعت EntityFramework
#dotnet #entityframework #performance
https://news.1rj.ru/str/SoftwarePhilosophy/900

ـــــــــــ

@SoftwarePhilosophy

قانون Conways در استفاده از مایکروسرویس‌ها در معماری نرم‌افزار بسیار قانون جالبی است. این روز‌ها در بسیاری از تیم‌های نرم‌افزاری بحث استفاده یا عدم استفاده از مایکروسرویس‌ها در معماری آینده تیم مطرح است. قانون Conways به طور کلی در مورد سیستم‌ها صحبت می‌کند. این قانون می‌گوید:
«اگر تیم و یا سازمانی در حال طراحی یک سیستم است (نه لزوما سیستم اطلاعاتی) طراحی نهایی آنها احتمالا شبیه ساختار ارتباطی همان سازمان است.»

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

این قانون گرچه اثبات نشده، ولی به طور ضمنی می‌گوید اگر می‌خواهید سراغ مایکروسرویس بروید، باید کل تیمتان هم مایکروسرویسی شود.

https://www.thoughtworks.com/insights/blog/demystifying-conways-law

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

http://ow.ly/8byp30emn9u


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

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

___

برگزاری جلسات بازنگری اسپرینت به شیوه ای نو

یکی از شکایتهای افراد تیم، تکراری شدن جلسات بازنگری اسپرینت است، "دائم چی خوب بود - چی بد بود و ... خوب که چی؟!"
یکی از هنرهای اسکرام مستر خوب پیدا کردن پرکتیس‌های مناسب برای تیم خود است.

یکی از این منابع سایت زیر است :

🛠 http://www.funretrospectives.com

این سایت حاوی شیوه های جدید و تازه برای برگزاری جلسات بازنگری اسپرینت است.

@iranagile

پنجمین نسخه از Swarm دوست‌داشتنی

احتمالا اپلیکیشن Foursquare همچنین Swarm را می‌شناسید. برای من Foursquare نمونه یک محصول بسیار موفق‌ست (حتی بالاتر از Instagram و Facebook)‌ که پیشرفت و پا گرفتنش را در ایران، لحظه به لحظه پیگیری کرده‌ام. هوشمندی بینظیری که در Gamification داشت و روش‌های اغواگرانه‌ای که برای وادار کردن کاربر به فعالیت استفاده می‌کرد از مهمترین دلایلی بود که من را به این محصول علاقمند می‌کرد.

بعدها که اپلیکیشن Swarm با هدف جدا کردن تکه‌ی شبکه اجتماعی Foursquare معرفی شد، فعالیت و پیگیری‌های من هم کمی کمتر شد ولی این تیم همیشه تاثیر خود را در کار حرفه‌ای من داشته‌ست. بطوریکه وقتی خواندم که اپلیکیشن جدید Foursquare بطور کامل در Sketch App طراحی شده، مهاجرت به این ابزار را برای خود یک الزام می‌دیدم.

تیم دیزاین این مجموعه، هم‌اکنون نسخه 5.0 از اپلیکیشن Swarm را منتشر کردند که دستخوش تغییراتی بسیاری شده‌است.
مقاله امروز، داستانی‌ست از زبان یکی از طراحان محصول این تیم که به بررسی روند این بازطراحی می‌پردازد و نکات جالبی در آن نهفته‌ست:
- می‌توان متوجه دید و دغدغه‌های یک تیم دیزاین در این سطح، در روند بازطراحی محصول شد.
- می‌توانید نمونه‌ای از Style Guideهایی را که در تیم‌های دیزاین دیگر ساخته می‌شود، ببینید.
- متوجه می‌شوید که یکی از وظایف شما به عنوان دیزاینر، به اشتراک‌گذاری ایده‌ها و طرح‌ها و گرفتن بازخوردهاست. در هر سطحی که باشید.
و …

پیشنهاد می‌کنم همین حالا این داستان زیبا را مطالعه کنید.

https://medium.com/foursquare-direct/how-we-designed-foursquare-swarm-5-0-d774b3164f3f

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

#تیم #بازطراحی #محصول #Swarm
@Dexign دیزاین

___

اگر دوستانی دارید که نه تنها برنامه نویس هستند، بلکه اعتقاد دارید «مهندس نرم‌افزار» هم هستند، آنها را به کانال @SoftwarePhilosophy دعوت کنید.
این پیغام را برای آنها Forward کنید.

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

یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»

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

فرض کنید می‌خواهید شغل بعدی خود را انتخاب کنید و تصمیم به رفتن به یک شرکت جدید دارید. واقعا آیا این بهترین تصمیم است؟
• این تصمیم می‌تواند در حال حاضر (سال ۲۰۱۵) بهترین تصمیم شما باشد.
• در انتهای ماه ممکن است به این نتیجه برسید که این تصمیم، نسبتا خوب بوده‌است زیرا شغل پر استرسی است.
• در سال ۲۰۱۶ ممکن است به این نتیجه برسید که تصمیم بدی گرفته‌اید چون شغل بسیار سختی است.
• در سال ۲۰۱۷ ممکن است به این نتیجه برسید که بدترین تصمیم ممکن را گرفته‌اید زیرا علی‌رقم تمام زحماتتان شرکت ورشکست شده!
• و در نهایت در سال ۲۰۲۰ به این نتیجه برسید که بهترین تصمیم تمام عمرتان را گرفته‌اید، زیرا با استفاده از تجربه‌ای که از آن شرکت به دست آورده‌اید حالا مدیرعامل شرکت مایکروسافت شده‌اید!

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

در مقاله زیر توضیح داده‌شده‌است که چگونه «تصمیم‌های به اندازه کافی خوب» در طول زمان می‌توانند به یک «بهترین تصمیم» تبدیل شوند.

http://mehrandvd.me/2016/12/12/good-enough-decision-towards-best-decision/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

Good Enough Decisio

شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

تخمین زمان یک پروژه کار آسانی نیست، مخصوصا اگر بخواهید خیلی دقیق باشید. ولی اغلب موارد مشکل تخمین این نیست که خیلی دقیق نیست، بلکه مشکلش این است که خیلی پرت است!
یکی از شایع‌ترین عواملی که باعث می‌شود تخمین زمانی یک پروژه خیلی اشتباه باشد، تفاوت قائل نشدن بین دو مفهوم خیلی مهم است: «تخمین زمان» و «تخمین کار».
«تخمین زمان» مفهومی است که مدیران پروژه دوست دارند در مورد آن صحبت کنند. وقتی صحبت می‌کنند دائما به دنبال شنیدن تخمین زمانی هستند. برای مثال جمله‌ای مانند «این کار تا پنجشنبه هفته بعد انجام می‌شود» جمله‌ای است که زمان انجام شدن کار را تخمین می‌زند.
در مقابل «تخمین کار» مفهومی است که معمولا برنامه‌نویسان دوست دارند در مورد آن صحبت کنند. آنها ترجیح می‌دهند بگویند که این کار به چقدر زمان نیاز دارد. مثلا کاری است که به ۳ روز زمان نیاز دارد. مثلا جمله «این کار به یک هفته کار نیاز دارد» به این معنی نیست که یک هفته دیگر این کار تمام می‌شود و صرفا حجم کار مورد نیاز بیان شده.

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

پست زیر این دو مفهوم را معرفی کرده و تفاوت آن‌ها را در مدیریت پروژه شرح داده‌است.

http://mehrandvd.me/2017/08/02/effort-vs-time-estimation/

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

http://ow.ly/958i30erVZs

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

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

___

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

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

http://way2pay.ir/73221

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

۱. قانون Conways در استفاده از مایکروسرویس‌ها در معماری نرم‌افزار

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

۲. برگزاری جلسات بازنگری اسپرینت به شیوه ای نو (Iran Agile)

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

۳. پنجمین نسخه از Swarm (دیزاین)

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

۴. یک تصمیم «به اندازه کافی خوب» به سوی «بهترین تصمیم»

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

۵. شایع‌ترین دلیل تخمین زمان اشتباه یک پروژه

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

۶. راز تولید چابک در دل بزرگ‌ترین بانک ایران (راه پرداخت)

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

ـــــــــــ

@SoftwarePhilosophy

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

___

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

محصولی مانند BMW واقعا چگونه در ذهن ما به عنوان یک محصول با کیفیت شکل گرفته است؟ آیا ما تخصص بررسی عملکرد موتور و گیربکس آن را داریم؟ آیا مقایسه‌ای فنی روی آن انجام داده‌ایم تا بفهمیم ماشین BMW یک محصول با کیفیت است؟
در حقیقت یک محصول را مفهومی به نام «نقاط تماس» یا Touch Points تعریف می‌کند. نقاط تماس مجموعه لحظاتی است که مشتری محصول را تجربه می‌کند. یک نقطه تماس می‌تواند لحظاتی باشد که مشتری با آن کار می‌کند، یا لحظاتی که مشتری پوستر محصول را می‌بیند و یا زمانی که صدای تیم پشتیبانی شما را از پشت تلفن می‌شوند.

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

http://mehrandvd.me/2016/10/02/touch-point-real-percepction-product/

#مهران_داودی
لینکدین:
https://ir.linkedin.com/in/mehrandvd

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

___

☕ وقتی فرهنگ استراتژی را بعنوان صبحانه می‌بلعد

شاید بدون شک بتوان گفت که امروز اساسی ترین مشکل کسب وکارها در دنیا، نیروی کار است، در صنعت IT که بشدت وابسته به نیروی متخصص بوده و بخصوص در ایران که کمبود نیروی متخصص و پایین بودن بهره وری (بدلایل مختلف مثل علاقه به کارآفرین شدن، اقتصادی، سیاسی، محیط زیستی، تحریم و…) بشدت محسوس است. بدلیل همین مشکل بزرگ شرکتها دائم در پی راهی هستند تا بهره وری نیروی انسانی خود را بالا ببرند. اما راه اساسی برای این کار چیست؟

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

پس با ده میلیون می خواهیم برای شرکت و سازمان فرهنگ بخریم.

سوال اساسی این است که آیا می شود فرهنگ را خرید؟

اما شاید یکسری دوستان به من ایراد بگیرن، “آقا ما نتیجش رو دیدیم”، یا مثلا “این شرکت های خارجی که خیلی بیشتر از ما حالیشون هست”.

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

فرهنگ چیست؟ کیست؟ چطوری است؟

فرهنگ یعنی “آنگونه که ما در عمل رفتار می کنیم” نه آنچیزی که تظاهر یا فکر می کنیم. پس این منشور اخلاقی و یا سخنرانی هایی که داریم؛ “ما یک شرکت مشتری مدار هستیم، ما به نیروهامون اعتماد کامل داریم” اسمش فرهنگ نیست، آنچیزی که در عمل می بینیم فرهنگ واقعی است “مثلا وقتی یک مشتری عصبانی زنگ میزنه و رفتاری که ما می کنیم، یا وقتی در شرکت زیر آب هم رو میزنیم و می گوییم بهم خیلی اعتماد داریم”

فرهنگ، استراتژی رو به عنوان صبحانه میخوره، یعنی چی؟

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

افسانه هایی در مورد فرهنگ

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

فرهنگ یک شب ایجاد نمی شود و البته یک شبه هم از بین نمی رود

خوبی یا بدی فرهنگ این است، نه یک شب ایجاد می شود و نه یک شب از بین می رود، تغییر فرهنگ نیاز به یک فرآیند چند مرحله ای دارد، که به مرور باید اجرا شود. تغییر فرهنگ چیزی نیست که شما از اول برنامه ریزی کنید و آن را اجرا کنید، بلکه باید برنامه های کوچکی داشته باشید، آن را اجرا کنید، نتیجه را بسنجید، دوباره برنامه ریزی کنید و دوباره اجرا کنید و … .

ادامه در لینک زیر 👇👇

https://goo.gl/dHHycC

@iranagile

سرویس Figma 2.0: ابزاری برای تمام فصول

وقتی ابزار Sketch معرفی شد، من کاربر Photoshop بودم و به خاطر سال‌ها کار با این رفیق قدیمی‌ام و حفظ بودن تمام میانبرها، ضعف‌ها و قوت‌هایش، دلم نمی‌خواست به سمت ابزار جدیدی بروم. کمی گذشت و Sketch با بروزرسانی‌هایش، همه را شگفت‌زده کرد و تیم‌های دیزاین قوی مثل Foursquare به سمت آن رفته و اپلیکیشن خود را با آن بازطراحی کردند.
طلسم را شکستم و استفاده از Sketch را آغاز کردم. این اتفاق به قدری لذتبخش بود که به نقطه عطفی از زندگی کاری‌ام بدل شد و از آن پس هر ابزار جدیدی را امتحان می‌کنم.

چندی قبل، خبر انتشار یک ابزار Collaborative طراحی رابط کاربری به اسم Figma را خواندم و زمانی را برای تیم دیزاین شرکت خالی کردم تا این ابزار را تست کنیم. چند صفحه از یک اپلیکیشن آشپزی را طراحی کردیم که نتایج آن روی Behance تیم‌مان قابل مشاهده‌ست:
https://www.behance.net/gallery/49456671/COOKY-APP

بعد از تجربه خوب کار با Figma، اخبار آن را مشتاقانه‌تر دنبال می‌کردم. تیم پرشور و هیجان این ابزار کاربردی، حالا نسخه دوم از ابزار خود را معرفی کردند که امکان Prototyping و همچنین امکانی به اسم Developer Handoff را برای کاربران خود به ارمغان آورده است. Developer Handoff ویژگی‌ست که به دیزاینرها اجازه می‌دهد یک نسخه از فایل دیزاین خود را بصورت View Only و غیرقابل ویرایش با توسعه‌دهنده پروژه به اشتراک بگذارند. توسعه‌دهنده با کلیک روی هر لایه می‌تواند ویژگی‌های آن را بصورت غیرقابل ویرایشی ببیند و حتی آیکن‌ها و سایر Assetهای مورد نظر خود را مستقیما از همان فایل، با اندازه و فرمت مد نظرش، خروجی بگیرد.

ابزار Figma، بصورت کامل از فرمت‌های گرافیک بُرداری (Vector) پشتیبانی می‌کند و به راحتی می‌توانید از آن‌ها در طراحی‌های خود استفاده کنید.
مقاله امروز، معرفی ویژگی‌های جدید Figma، از زبان بنیانگذار و مدیرعامل این سرویس، Dylan Field است.

به نظر من آینده از آنِ ابزارهای Collaborative بوده و Figma تا کنون بینظیر عمل کرده است.
مقاله امروز را از دست ندهید:
https://blog.figma.com/figma-2-0-now-with-prototyping-and-developer-handoff-1b309a5d025c

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

#معرفی #ابزار #Figma
@Dexign دیزاین

___

ممکن است در فرایند توسعه‌ی برنامه‌های 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

___

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

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

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

http://cssguidelin.es/

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

http://ow.ly/IdOy30aYW4S

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

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

___