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

۱. نکاتی برای بهتر ارائه کردن ایده‌های استارتاپی

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

۲. شبیه ساز HoloLens برای برنامه‌نویسان

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

۳. شهره‌ی شهر شدن با تو چه آسان، سخت است! (فلسفه دیزاین)

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

۴. استراتژی و نه تکنولوژی

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

ـــــــــــ

@SoftwarePhilosophy

تئوری اسب مرده!

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

یک ضرب‌المثل قدیمی هندی می‌گوید: اگه دیدین سوار یه اسب مرده هستید، بهترین استراتژی اینه که پیاده شین.

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

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

مفهومی که هنگام خواندن این ضرب‌المثل تداعی می‌شود، مفهوم Root Cause است. اغلب مشکلاتی که در اطراف ما وجود دارد دارای دلایل واضح و سطحی است که غالبا منجر به حل آن مشکل نمی‌شود. از طرفی، اگر تلاش کنید برای یک مشکل عمیق فکر کنید و به Root Cause آن برسید، مشکلات به طور عجیبی حل می‌شوند و حتی با حل یک مشکل، مشکلات دیگری نیز خود به خود حل می‌شوند.

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

https://mehrandvd.me/2018/06/27/the-dead-horse-theory/


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

https://ow.ly/AGJa30kQv8N

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

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


___

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

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

https://yalantis.com/blog/how-much-does-it-cost-to-develop-an-app/

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

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

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


___

مدیریت Blob life cycle در Azure

سناریو زیر را در نظر بگیرید:

سندی دارید که در ماه اول بصورت متناوب به آن دسترسی خواهید داشت ولی در دو ماه بعد از آن برخی اوقات از آن استفاده می‌کنید و پس از آن به ندرت. در نهایت پس از ۷ سال در نظر دارید آن را حذف کنید.
از طرفی تنظیم درست Storage Tier هم در قیمت و هم در سرعت دسترسی تاثیر بسیاری دارد.

در سیستم جدید Azure Blob Storage lifecycle management می‌توانید policy را به گونه‌ای تنظیم کنید که در ماه اول blob در Tier Hot، پس از آن Cool و پس از آن در Archive قرار گیرد. بصورت خلاصه سرویس همیشه در بهترین Tier قیمتی ممکن قرار خواهد داشت و در آخر آن حذف می‌شود. این تکنیک یکی از هزاران تکنیک جدیدی هستند که برای مدیریت بهتر هزینه‌ها به اکوسیستم Azure اضافه شده‌است.

https://azure.microsoft.com/en-us/blog/azure-blob-storage-lifecycle-management-public-preview/

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

https://ow.ly/nrDP30kSHux

#کامران_کمایی (https://ow.ly/zsuj30kSHjB)

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


___

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

استفاده از تاریخ و زمان در زبان‌های برنامه‌نویسی همواره برای برنامه نویسان دردسر ساز بوده است. این مشکل به ویژه برای برنامه نویسان ایرانی مشهود است زیرا همیشه درگیر تبدیل تاریخ‌های میلادی و شمسی به یکدیگرند.
اما واقعا چرا مفهوم تاریخ در علم کامپیوتر و متعاقبا زبان‌های برنامه‌نویسی دردسر سازند؟
در مورد یک عدد عبارت ۱۰۰ تا بعد از ۳۰۰ چند می‌شود معنی دقیقی دارد و جواب ۴۰۰ است. ولی در مورد تاریخ عبارت «یک ماه» بعد از ۱۶ شهریور چه روزی است جواب دقیقی ندارد. آیا منظور از یک ماه ۳۰ روز است یا ۳۱ روز؟ با هر کدام از این فرضیه‌ها جواب ممکن است ۱۵ شهریور یا ۱۶ شهریور باشد.
مقاله زیر به صورت کامل‌تری پیچیدگی‌هایی را که تاریخ و زمان با خود به دنیای برنامه‌نویسی آورده‌اند را توضیح داده‌است.

https://mehrandvd.me/2016/07/26/datetime-complexities-programming-languages/

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

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


___

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

برای Sync کردن دیتابیس‌های مختلف معمولا نیاز دارید تغییرات یک دیتابیس را از طریق یک شماره مانند ورژن متوجه شوید. به عبارتی برای یک دیتابیس نیاز دارید همیشه یک عددی داشته باشید که با هر تغییر اطلاعات یک شماره افزایش یابد. در SQL Server دو روش برای این کار وجود دارد. یکی استفاده از @@DBTS و دیگری تابع min_active_rowversion است. تفاوت این دو تابع در رفتار آنها حین انجام یک تراکنش است. اولی حین اجرای تراکنش تغییر می‌کند و دومی پس از اتمام تراکنش به روز می‌شود. دانستن دقیق تفاوت این دو کمک بسیاری در انجام موفق پروژه‌های همگام‌سازی اطلاعات می‌کند.
مقاله زیر تفاوت‌های این دو روش را با مثال‌های خوبی توضیح داده‌است.

https://www.mssqltips.com/sqlservertip/3423/sql-server-rowversion-functions-minactiverowversion-vs-dbts

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

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

___

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

۱. تئوری اسب مرده!

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

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

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

۳. مدیریت Blob life cycle در Azure

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

۴. پیچیدگی‌های اضافه کردن تاریخ و زمان برای برنامه‌نویسان

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

۵. مقایسه rowversion و @@DBTS در SQL Server

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

ـــــــــــ

@SoftwarePhilosophy

بازآفرینی دیزاین‌های روزانه: Backspace

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

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

شما درگیر چه عادت‌هایی هستید و به نظرتان چگونه می‌شود از محدودیت‌های ذهنی این عادت‌ها خارج شد؟

ایده جذاب آقای Anslow را از دست ندهید:

https://medium.com/open-prototype/backspace-rethought-aa343485513f

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

#بازآفرینی_روزانه #ایده #Backspace
@Dexign فلسفه دیزاین

___

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

نوشتن «بات‌» هوشمند در دنیای رقابتی بات‌ها می‌تواند خیلی جذاب باشد. مدتی است مایکروسافت چند پروژه‌ هوش مصنوعی را تحت عنوان Cognitive Science شروع کرده که به تشخیص عکس و تشخیص گفتار کمک می‌کند. همچنین امکان یکپارچه کردن آن با زیر ساخت Bot Framework می‌تواند منجر به تولید بات‌های بسیار کارایی شود.
در لینک زیر نحوه استفاده از هوش مصنوعی پروژه‌های Cognitive در بات‌ها آموزش داده شده است.

https://www.dotnetcurry.com/csharp/1281/simple-bot-using-microsoft-bot-framework-cognitive-services

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

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


___

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

بر خلاف زبان‌هایی مانند C++ در زبان C# مفاهیم class و struct امکانات مشابهی دارند و در بسیاری از موارد می‌توانند به جای یکدیگر استفاده شوند. به همین منظور هنگام معماری نرم‌افزار نقاط بسیاری وجود دارد که نیاز به تصمیم گیری برای انتخاب یکی از آنها است. به طور خلاصه class ها به عنوان reference type شناخته می‌شوندو در Heap نگهداری می‌شوند، در حالی که struct ها به عنوان value type شناخته می‌شوند و در stack نگهداری می‌شوند. یاد گرفتن دقیق این دو مفهوم و تفاوت‌های آنها کمک بسیاری در انتخاب درست آنها در معماری می‌کند.
لینک زیر مربوط به بخشی از کتاب Framework Design Guidelines (FDG) است که به طور کامل در مورد این موضوع توضیح داده‌است. این کتاب استانداردی است که تمام برنامه‌نویسان در مایکروسافت باید آن را مطالعه کرده باشند و نکات آن را رعایت کنند.

https://msdn.microsoft.com/en-us/library/ms229017(v=vs.110).aspx

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

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


___

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

در یک مصاحبه با Eric Lippert (یکی از اعضای سابق تیم زبان C#) از او پرسیده شده بود «آیا سی‌شارپ یک زبان strongly typed است یا weakly typed». جواب او به این سوال این بوده: «بله!» به نظر جواب غیر واضحی می‌آید. اریک در ادامه توضیح داده که مشکل از خود سوال است و اگر در سوال «یا» را به «و» تبدیل کنید، جواب من هنوز «بله» است!!
در پست زیر از بلاگ اریک، این مفاهیم با جزئیات بیشتری مانند statically typed، memory safe و type safe توضیح داده شده‌است.

https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language

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

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


___

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

مفهوم static class در زبان‌های برنامه‌ نویسی شی‌گرا می‌تواند بسیار گمراه کننده باشد. اصولا بهتر است معماری نرم‌افزار طوری انجام شود که کمترین نیاز به این نوع کلاس باشد. یکی از نکات مهم در مورد این مفهوم این است که برنامه‌نویسان باید حواسشان باشد با این مفهوم به عنوان «سطلی برای نگهداری کدهای متفرقه» استفاده نشود. معمولا کدی که به اندازه کافی به محل درست نوشتن آن فکر نشده، اولین مکانی که برای آن مناسب به نظر می‌رسد یک static class است.
لینک زیر مربوط به بخشی از کتاب Framework Design Guidelines (FDG) است که به طور کامل توضیح داده‌است که در چه مواقعی مجاز به استفاده از static class ها هستیم و چه مواقعی نه. این کتاب استانداردی است که تمام برنامه‌نویسان در مایکروسافت باید آن را مطالعه کرده باشند و نکات آن را رعایت کنند.

https://msdn.microsoft.com/en-us/library/ms229038(v=vs.110).aspx

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

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


___

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

بهترین راه برای تست کارایی یک نمونه‌ی اولیه واسط کاربری، مشاهده دقیق افرادیست که برای اولین بار از آن استفاده می‌کنند. با این کار می‌توان به راحتی متوجه شد که چه قسمت هایی گیج کننده است، چه قسمت هایی نامفهوم است یا کارایی مناسب را ندارد و از آن‌ها در جهت بهبود طراحی استفاده کرد.
برای انجام این کار با توجه به اینکه کاربر نهایی چه کسی است و چه اهدافی دارد، یک سناریو یا داستان نوشته می شود و کارهایی که شخص باید انجام دهد را مشخص می‌کند اما در آن به جای اینکه مشخصا از شخص خواسته شود که "کار X را انجام بده!"، یک سناریو طرح می‌شود که این فضا را به شخص بدهد که کار X را انجام دهد. برای مثال، یک سناریو می‌تواند این باشد: "شما در‌حال برنامه‌ریزی سفر به شهر اصفهان از تاریخ ۳ فروردین تا ۶ فروردین هستید و احتیاج دارید که بلیط هواپیمای خود را بخرید. برای انجام این کار به سایت هواپیمایی ماهان می روید.". و متوجه می‌شویم که کاربر آیکون خرید بلیط را خیلی سخت پیدا کرده است. این آزمایش به طراح نشان می‌دهد باید طراحی تجربه کاربری را تغییر دهد...
در مقاله ی زیر می توانید با این روش کاملتر آشنا شوید.

https://www.nngroup.com/articles/task-scenarios-usability-testing

#زهره_مرادی

لینکدین:
https://ir.linkedin.com/in/zohre-moradi

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

___