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

۱. قابلیت های جدید Entity Framework Core (Iran .Net)

https://t.me/SoftwarePhilosophy/1219

۲. بررسی مفهوم blockchain

https://t.me/SoftwarePhilosophy/1220

۳. معرفی ۱۰ کتابخانه جذاب روی GitHub برای React

https://t.me/SoftwarePhilosophy/1222

۴. راهنمای کامل طراحی آیکن‌های Flat (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1223

۵. خدمات شرکت‌های معتبر دنیای تکنولوژی برای دانشجویان (Iran .Net)

https://t.me/SoftwarePhilosophy/1224

۶. تشخیص و خلق مفهومی به نام فضا برای معماران نرم افزار

https://t.me/SoftwarePhilosophy/1226

۷. بررسی مفهوم Lambda Expression در جاوا

https://t.me/SoftwarePhilosophy/1228

۸. مصاحبه با یک دیزاینر: پاول دباشیش از فیسبوک (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1230

۹. شباهت‌های دوازبانان در فوتبال و رهبران تیم‌ها

https://t.me/SoftwarePhilosophy/1232

۱۰. همه چیز در مورد Job to be done (Iran Agile)

https://t.me/SoftwarePhilosophy/1233

۱۱. تمرکز روی مشتری، نیم‌نگاهی به رقیب (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1235

ـــــــــــ

@SoftwarePhilosophy

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

امنیت یکی از دغدغه‌های مهم نرم‌افزارهای large scale است. این دغدغه نه تنها به خود نرم‌افزار بر می‌گردد، بلکه بیشتر به تیم‌هایی برمی‌گردد که در حال توسعه این سیستم‌ها هستند. اینکه تیم برنامه‌نویسی بتواند یک ویژگی امنیتی مانند لاگین را بنویسد بسیار تفاوت دارد با اینکه بتواند یک کد را امن بنویسد. «توانایی کد نویسی امن» یک مهارت است که مخصوصا برنامه‌نویسان سیستم‌های large scale مانند سیستم‌های بانکی یا ERP باید از آن برخوردار باشند.
یکی از مهمترین تعارضات تیم‌های برنامه‌نویس با دپارتمان‌های امنیت، این طرز تفکر است که امنیت «یک تست نهایی» است که باید در انتها انجام شود. این رویکرد اشتباه غالبا باعث می‌شود ریسک‌های امنیتی زیادی متوجه سازمان شود. در تیم‌های حرفه‌ای امنیت یک کار روزانه است که همه هر روز در حال انجام آن هستند.
اخیرا دپارتمان امنیت «بهسازان» در بانک ملت پروژه جالبی را به نام «مسابقه CTF» یا Capture The Flag را اجرا کرده‌است. طی این رویداد با برگزاری یک سری مسابقات جذاب برنامه‌نویسی امنیتی، به طور ناخودآگاه دانش امنیتی تمام افراد سازمان، مخصوصا برنامه نویسان بالا رفته‌است. نکته جالبه پلتفرم بهسازان این بود که آن را طوری طراحی کرده‌اند که می‌توانند در اختیار سایر سازمان‌ها نیز قرار دهند تا متناسب با بیزنس خود آن را پیکربندی کنند و موجب آموزش این مهارت‌ها به سازمان خود شوند.

http://mehrandvd.me/2017/05/23/capture-flag-secure-software/

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

http://ow.ly/p03w30cbHdO

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

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


___

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

حذف حجم زیادی از سطرها از دیتابیس با اجرای دستور DELETE می‌تواند بسیار پر هزینه و زمان‌بر باشد. برای بهبود عملکرد و سرعت عملیات حذف باید Foreign Key ها، Index ها را هم بررسی کرد. ولی پس از بررسی و بهبود توسط این عوامل، راه بعدی استفاده از Delete Chunks است. شکستن DELETE های بزرگ به تکه‌های کوچک‌تر می‌تواند کمک زیادی به بهبود سرعت کند.

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


https://sqlperformance.com/2013/03/io-subsystem/chunk-deletes

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

http://ow.ly/CcQz30bhNiQ


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

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


___

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

دییییگر نگران نباشید!

با افزونه «Sheet Explorer» همه چیز راحت می‌شود:
- شیت‌ها رو راحت و واضح می‌بینید.
- می‌تونید بین شیت‌ها جستجو کنید.
- می‌تونید وابستگی هر شیت رو به شیت‌های دیگه به صورت درختی ببینید.

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

http://mehrandvd.me/2016/10/10/excel-sheet-explorer-turning-shits-to-sheets/

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

http://ow.ly/Jmw130jZkcI

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

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


___

🔵 بک‌لاگ‌های چوبی، اجداد بک‌لاگ‌های محصول

پیشینه آنچه ما امروز به نام بک‌لاگ (Backlog) می‌شناسیم شاید به عصر نوسنگی، حدود ۱۰ هزار سال قبل، بازگردد!

زمانی که انسان خردمند (Homo sapiens) از عادت صدها هزار ساله مهاجرت و کوچ‌نشینی خود دست کشید و به یکجانشینی روی آورد. او به‌زودی آموخت که چگونه باید برای گذران زمستان‌های سرد، در فصول گرم‌تر سال هیزم کافی «جمع‌آوری» و «نگهداری» کند. او بدون آنکه بداند، مفهومی ارزشمند به نام بک‌لاگ را اختراع کرده بود!

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

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

خصوصیات بک‌لاگ‌های چوبی، احتمالاً بیش از این‌هاست. ویژگی دیگری می‌شناسیم که در لیست بالا نیاورده باشم؟

به نظر می‌رسد دلیل تأکید چارچوب‌های چابک، مانند اسکرام، بر واژه بک‌لاگ برای «فهرستی اولویت‌دار از ویژگی‌های ارزش‌آفرین محصول»، اشاره غیرمستقیم و ظریف به اشتراکاتی است که با بک‌لاگ های چوبی قدیمی دارد.

آیا بک‌لاگ محصول شما نیز به همان خوبی بک‌لاگ هیزمی موجود در کلبۀ اجداد قرون‌وسطایی‌مان هستند؟ فصول سرد در طول پروژه‌های توسعه محصول چه زمانی فرامی‌رسند؟

آیا عدم قطعیت موجود در پروژه‌های توسعه محصول، همچنین ماهیت چرخش انتقالی پرشتاب این‌گونه پروژه‌ها و درنتیجه فرارسیدن زودبه‌زود فصول تاریک، سرد و پر چالش در آن‌ها، مؤید آن نیست که لازم است زمان بیشتری صرف بک‌لاگ‌های محصولمان کنیم؟ حتی بیش ازآنچه همکاران نوسنگی‌مان برای رسیدگی به بک‌لاگ‌های چوبی‌شان صرف می‌کردند!

http://vrgl.ir/ko8kP

سلام و عرض ادب خدمت دوستان عزیز
شاید بارها برای شما پیش اومده باشه که بخواهید مثلا یک موردی رو در Administration در SQL Server تست کنید ولی ابزار یا تجهیزاتش رو نداشته باشید
به عنوان مثال مثلا تمایل دارید Replication رو راه اندازی کنید یا AlwaysON رو راه اندازی کنید ولی سیستم به اندازه کافی ندارید و همچنین PC شما نیز قدرت کافی نداره بخواهید مثلا VM بیارید بالا یا اینکه تنظیمات اولیه شبکه برای شما دشوار باشه.
سایت Virtual Lab مایکروسافت این امکانات رو در اختیار شما قرار میده.
تنها چیزی که نیاز دارید فقط یک اکانت ایمیل مایکروسافت هست و بس.!
در حوزه های مختلف خودش Lab هایی رو برای شما آماده سازی کرده و همچنین یک سری Documentation نیز آماده کرده و یک زمانی مشخص کرده.
به اندازه مورد نیاز اون Feature به شما منابع میده و شما به راحتی به سیستم ها لاگین میکنید و طبق اون مستنداتی که بهتون داده مراحل رو طی میکنید و میتونید راه اندازی Feature مورد نظر رو یاد بگیرید.
لینک سایتش رو قرار میدم امیدوارم که مفید واقع بشه.

ارادتمند شما
حمیدرضا صادقیان
ID: @Hamidreza_Sadeghian
SQL Server Channel : @SQL_Server

https://www.microsoft.com/handsonlabs/SelfPacedLabs

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

۱. امنیت در نرم‌افزارهای large scale

https://t.me/SoftwarePhilosophy/1238

۲. نوشتن کوئری‌های DELETE بهینه برای حجم دیتای زیاد

https://t.me/SoftwarePhilosophy/1240

۳. آشنایی با افزونه Sheet Explorer برای فایل‌های اکسل

https://t.me/SoftwarePhilosophy/1241

۴. بک‌لاگ‌های چوبی، اجداد بک‌لاگ‌های محصول (Iran Agile)

https://t.me/SoftwarePhilosophy/1242

۵. آشنایی با وبسایت سایت Virtual Lab مایکروسافت برای تست‌های SQL Server (SQL Server)

https://t.me/SoftwarePhilosophy/1243

ـــــــــــ

@SoftwarePhilosophy

غلبه بر میمون خشنودی‌های لحظه‌ای،
یا چگونه یک انسان دقیقه نودی نباشیم!

آغاز سال ۱۳۹۷ را به همه همراهان این کانال تبریک گفته و آرزوی سالی pixel-perfect و پر از حال خوب برای همه شما دارم.
اکثر ما شروع سال جدید را بهانه قرار می‌دهیم برای هدف‌گذاری‌های جدید در زندگی. چیزهایی که همیشه به دنبال آن‌ها بودیم از ذهن گذرانده و با نیم‌نگاهی به سالی که گذشت و مسیری که پیموده‌ایم، اهدافی را که قصد داریم در سال آینده به آن‌ها برسیم لیست می‌کنیم.

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

پست امروز برای کمک به هدف‌گذاری همه ما در سال جدید انتخاب شده است. امروز یک سخنرانی TED را معرفی خواهیم کرد که آقای Tim Urban در آن از چگونگی نوع تفکر انسان‌های دقیقه نودی پرداخته و در انتها راهکاری کاملا کاربردی برای آن ارائه می‌دهد.

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

https://ted.com/talks/lang/fa/tim_urban_inside_the_mind_of_a_master_procrastinator

(زمان حدودی مشاهده، ۱۴ دقیقه)

#مدیریت #هدفگذاری #سخنرانی
@Dexign فلسفه دیزاین

___

غلبه بر میمون خشنودی‌های لحظه‌ای،
یا چگونه یک انسان دقیقه نودی نباشیم!

@Dexign فلسفه دیزاین

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

اثری که Body language بر خود فرد می‌گذارد، اگر بیشتر از اثری که بر مخاطب می‌گذارد نباشد، کمتر هم نیست.

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

https://www.ted.com/talks/amy_cuddy_your_body_language_shapes_who_you_are

#افشین_علیزاده
لینکدین:
https://ir.linkedin.com/in/afshinalizadehbehjati

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

___

نسل جدید برنامه‌های cross-platform: برنامه‌های PWA

برنامه‌های PWA یا Progressive Web App با سرعت چشمگیری در حال رشد هستند و به نظر می‌رسد پتانسیل بالایی در تسخیر بازار داشته باشند. این ایده به شدت توسط شرکت‌های گوگل و مایکروسافت در حال پشتیبانی است. گوگل از آنجاییکه درآمد اصلی خود را وب می‌داند با آمدن این نسل برنامه‌ها سود بیشتری به دست خواهد آورد. از طرفی مایکروسافت مشکل گپ برنامه در App Store خود را می‌تواند با این تکنولوژی حل کند. آنها حتی یک Bing Crawler نوشته‌اند که وب‌سایت‌هایی را که PWA هستند را به طور خودکار به Store اضافه کند. در این میان اپل به نظر خیلی راضی نمی‌رسد، زیرا یکی از مدل‌های درآمدی اپل از اکوسیستم توسعه اپ برای Apple Store بوده‌است.
بسیاری از شرکت‌های بزرگ نظیر Twitter, Instagram, Uber, Lyft, Pinterest و ... در حال روی آوردن به این رویکرد هستند. مایکروسافت نیز رسما اعلام کرد که از Redstone 4 به بعد این نوع اپ مستقیما از store ها قابل نصب هستند.

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

https://www.windowscentral.com/what-are-progressive-web-apps-video

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

http://ow.ly/QMlV30k6wdZ

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

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


___

🔵 توسعه ترس محور یا Fear Driven Development چیست؟

روز گذشته اسکات هنسلمن نوشته‌ای رو در وبلاگشمنتشر کرد و از ترس‌هایی که تبدیل به یک روال توسعه نرم‌افزار می‌شوند گفت. او نام توسعه ترس محوریا Fear Driven Development را برای این موضوع انتخاب کرده. 

😨 ترس سازمانی

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

این «فلج تحلیلی» کل پروژه را کند می‌کند. یک نوشته خوب تحت عنوان «۱۰ راه برای از دست دادن تیم» وجود دارد که بسیاری از این رفتارهای منفی را پوشش داده. مواردی مثل:

ممنوع کردن جلسات تک به تک

عدم به اشتراک‌گذاری اطلاعات

القاء اینکه هر کسی را می‌توان جایگزین کرد

مدیریت به سبک Micromanagement

همه این رفتارها باعث افزایش ترس محیطی و ایجاد ابری از اضطراب در سازمان می‌شود

😨 ترس از دست دادن شغل

یک نوع دیگر از Fear Driven Development وقتی است که سازمان با القای این مطلب که با هر نشانه‌ای از مشکل در پروژه، برنامه‌نویس شغلش را از دست خواهد داد تلاش می‌کند برنامه‌نویس‌ها تا دیروقت سر کار بمانند و به صورت نامعقول به سختی کار کنند. تهدید شعلی هرگز باعث افزایش کارآیی تیم نمی‌شود.این کار تنها باعث نهادینه شدن احساسات منفی شده و همیشه باعث می‌شود که افراد از کار استعفا بدهند. 
این کار همچنین باعث می‌شود تا مدیران تصور کنند که تلاش‌های قهرمانانه، جزئی معمول و پذیرفته شده در روال توسعه نرم‌افزار است. فشار کار گاه به گاه یک چیز است، اما اگر هر Release نرم‌افزاری در تیم شما به معنی انجام تلاش‌های قهرمانانه است که به قیمت روابط شخصی شما تمام می‌شود، شما مشکل دارید.

😨 ترس از تغییر کد

یک نوع دیگر از Fear Driven Development وقتی است که بخش توسعه نرم‌افزار سازمان یا کل سازمان از کد می‌ترسند! شاید کد قدیمی باشد (legacy code) اما معمولاً کد قدیمی فقط به خوبی درک نمی‌شود. کد قدیمی تقریباً درست کار می‌کند، اما افراد از تغییرات حتی کوچک در کد به دلیل اینکه ممکن است باعث ایجاد اثرات جانبی بشوند واهمه دارند. ترس از رگرسیون باگ- بازگشت مجدد باگ‌هایی که بسته یا رفع شده‌اند نیز باعث استرس برنامه‌نویسان می‌شود.

https://goo.gl/CgYpdX

@iranagile

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

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

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

لینک زیر می تواند یک شروع خوب برای آشنا شدن با این مفهوم باشد.

https://medium.com/@joshelman/a-product-managers-job-63c09a43d0ec#.i6pcfk9wa


#کاروان_جافی

لینکدین:
https://uk.linkedin.com/in/karvan-jafi-96897027

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


___

هنر نوشتن پیغام‌های خطا

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

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

امروز می‌خواهیم به چگونگی نوشتن پیغام‌های خطای خوب را بررسی کرده و این هنر را فرا بگیریم. با یادگیری این هنر، دیگر پیغام‌های اختصاصی محصول خود را خواهیم داشت که پاسخگوی کاربران محصول ماست.
در مقاله امروز از خانم Marina Posniak، یکی از UX Writerها شرکت Spotify، با عنوان مقدمه‌ای در باب اهمیت Copywriting و بطور مشخص پیغام‌های خطا، قدم به قدم ما را در فراگیری این هنر همراهی می‌کند.

مقاله امروز را از دست ندهید:
https://thestyleofelements.org/the-art-of-the-error-message-9f878d0bff80

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

پ. ن.
قبلا درباره پیغام خطای «نام کاربری و یا کلمه عبور شما اشتباه است.» صحبت کرده بودیم:
t.me/Dexign/223

#تجربه_کاربری #کپی_نویسی #پیغام_خطا
@Dexign فلسفه دیزاین

___

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

۱. چگونه یک انسان دقیقه نودی نباشیم! (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1245
https://t.me/SoftwarePhilosophy/1246

۲. تاثیرات «زبان بدن» بر خود فرد: Fake it until you Make it

https://t.me/SoftwarePhilosophy/1248
https://t.me/SoftwarePhilosophy/1249

۳. نسل جدید برنامه‌های cross-platform: برنامه‌های PWA

https://t.me/SoftwarePhilosophy/1250

۴. توسعه ترس محور یا Fear Driven Development چیست؟ (Iran Agile)

https://t.me/SoftwarePhilosophy/1251

۵. مدیریت محصول در شرکت‌های نرم‌افزاری

https://t.me/SoftwarePhilosophy/1254

۶. هنر نوشتن پیغام‌های خطا (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1255

ـــــــــــ

@SoftwarePhilosophy