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

۱. قابلیت‌های مهم یک مدیر فنی
#management #cto

https://telegram.me/SoftwarePhilosophy/571


۲. استفاده از واقعیت مجازی در ساخت بازی‌های کامپیوتری
#augmentedreality #kinectprogramming

https://telegram.me/SoftwarePhilosophy/574
https://telegram.me/SoftwarePhilosophy/573


۳. واقعیت مجازی و معرفی Wikitude
#augmentedreality

https://telegram.me/SoftwarePhilosophy/576


۴. رویکردهای مختلف فرآیند رفع باگ در چرخه توسعه نرم‌افزار
#softwareprocess #sdlc #bug

https://telegram.me/SoftwarePhilosophy/578


۵. فریم‌ورک AMP و فرآیند هماهنگ‌سازی سایت با مرورگرهای موبایل
#javascript #mobile

https://telegram.me/SoftwarePhilosophy/580


۶. معرفی فریم‌ورک JoinJS
#javascript #framework

https://telegram.me/SoftwarePhilosophy/582


ـــــــــــ

@SoftwarePhilosophy

«استارتاپ ویکند» یکی از رویدادهای جذابی است که مخصوصا برای برنامه نویسان می‌تواند بسیار مفید باشد.
https://modotech.ir

@SoftwarePhilosophy

___

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

www.modotech.ir

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

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

___

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

قورباغه را دوباره اختراع نکنید!

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


https://mehrandvd.me/2016/03/09/reinventing-the-frog/

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


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


___

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

کتابخانه LinqToTwitter یکی از LINQ Provder های جذاب ‌است که روی معماری LINQ بنا شده‌است. به وسیله این کتابخانه به راحتی می‌توانید روی توییتر با استفاده از LINQ جستجو کنید. معماری LINQ بسیار زیبا و قابل گسترش طراحی شده‌است. این معماری به این صورت است که خود LINQ به صورت یک «زبان پرس‌جو مستقل از تکنولوژی» طراحی شده‌است. سپس از مفهومی به نام LINQ Provider برای اجرای پرس و جو استفاده می‌شود. لیست Provider های زیر معمولا شناخته شده‌تر هستند:
• LinqToObjects
• LinqToSql
• LinqToEntityFramwork
• LinqToXml
اما با توجه به معماری LINQ می‌توان روی هر بستر اطلاعاتی LINQ Provider های جدید نوشت که LinqToTwitter یکی از آنهاست. در اینترنت می‌توان Provider های جذاب دیگری مانند LinqToFacebook را نیز جستجو کرد.

https://github.com/JoeMayo/LinqToTwitter

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

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

___

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

نسخه بعدی زبان جاوا یا Java 9 در راه است. مهمترین امکانات اضافه شده در نسخه قبلی Java 8 مفهوم Lambda، Stream و تغییرات API بود. در نسخه جدید Java 9 مهمترین تغییر، پروژه‌ Jigsaw است که هدف آن شکستن JRE به قطعات کوچک و ماژولار کردن کامپوننت‌های Java core است تا بتوان از آن در دستگاه‌های محاسباتی کوچک به راحتی استفاده کرد. ولی به غیر از این تغییر اساسی، تغییرات جذاب دیگری نیز در راه است. مهمترین این تغییرات عبارتند از:
1. Java + REPL (jshell)
2. Microbenchmarks
3. G1: a new garbage collector (maybe)
4. Full support for HTTP 2.0
5. Process API
6. Debugging in Production
در مقاله زیر این امکانات توضیح داده شده‌اند. همچنین در مورد تصمیم‌گیری برای اضافه کردن G1 به Java 9 و وضعیت آن صحبت شده‌است.

https://blog.takipi.com/5-features-in-java-9-that-will-change-how-you-develop-software-and-2-that-wont

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

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

___

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

طبق تحقیقات انجام شده به علت عدم وجود Onboarding در سازمان‌ها 16% از نیروهای تازه استخدام شده در همان هفته اول و 17% نیز در ماه اول از ادامه همکاری با شما منصرف می‌شوند. قاعدتا در ماه اول استخدام برای نیروهای جدید یک دروه‌ی آموزشی برگزار میشود. اگر این نیروی جدید بعد از یک ماه منصرف شود چه زیانی به سازمان وارد شده است:
• بدون شک فردی که مسئول آموزش به نیروی جدید است در آن 1 ماه راندمان سابق را ندارد به 2 دلیل: زیرا زمانی از روز را به آموزش تخصیص داده است و همچنین به علت سوالات نیروی جدید نمی‌تواند تمرکز لازم را روی کار خود داشته باشد.
• نتیجه‌ای که بعد از 1 ماه حاصل میشود چیزی بجز ضرر برای شما نیست. ۱- وظایفی که مسئول آموزش می‌توانست در 1 ماه انجام دهد به طور کامل انجام نشده است. ۲- شما بابت کاری که هیچ فایده‌ای برای سازمان نداشته است به مسئول آموزش حقوق داده‌اید.

از مزایای Onboarding می‌توان به موارد زیر اشاره کرد:

افزایش:
• رضایت شغلی
• عملکرد شغلی
• تعهد سازمانی
و همچنین کاهش:
• استرس شغلی
• ترک کار

لینک زیر به صورت شماتیک به مزایای Onboarding اشاره می‌کند.

https://business.linkedin.com/talent-solutions/blog/2014/06/what-do-new-hires-want-from-onboarding-infographic

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

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

___

مدیریت نسخه‌ها در طراحی RESTFul Web Api ها در معماری نرم‌افزارهای نسل جدید به یک مفهوم مهم تبدیل شده‌است. از آنجاییکه «تغییر» و بهبود یکی از فاکتور‌های جدا نشدنی در نرم‌افزار است و در نسل جدید نرم‌افزارها تغییر بسیار سریعتر اتفاق می‌افتند، مدیریت آن بسیار مهم است.
مدیریت نسخه‌ها در Web Api حتی می‌تواند در طراحی آن تاثیر بگذارد. برای مثال طراحی api ممکن است به روش‌های زیر باشد:
• /api/foo?api-version=1.0
• /api/foo?api-version=2.0-Alpha
• /api/foo?api-version=2015-05-01.3.0
• /api/v1/foo
• /api/v2.0-Alpha/foo
• /api/v2015-05-01.3.0/foo

در لینک زیر «اسکات هانسلمن» کتابخانه‌ای را برای مدیریت versioning در .NET را معرفی کرده‌است که معماری بسیار خوبی دارد و به راحتی می‌توان از آن استفاده کرد.

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

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

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

___

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

‍۱. معرفی استارتاپ ویکند
#startupweekend

https://telegram.me/SoftwarePhilosophy/585
https://telegram.me/SoftwarePhilosophy/586


۲. قورباغه را دوباره اختراع نکنید
#management

https://telegram.me/SoftwarePhilosophy/589


۳. کتابخانه LinqToTwitter
#linq #twitter

https://telegram.me/SoftwarePhilosophy/591


۴. امکانات اضافه شده به Java 9
#java

https://telegram.me/SoftwarePhilosophy/593


۵. مفهوم Onboarding و تاثیر آن در عملکرد تیم‌ها
#management

https://telegram.me/SoftwarePhilosophy/594


۶. معرفی کتابخانه‌ای در .NET برای مدیریت versioning
#dotnet #webapi #versioning

https://telegram.me/SoftwarePhilosophy/595


ـــــــــــ
@SoftwarePhilosophy

50 Shades of #FAFAFA
یا اشتباهاتی که همه ما دیزاینرها انجام دادیم

برای پروژه ۵ رنگ انتخاب کنید.
قوانین تایپوگرافی خودتون رو ابداع نکنید!
خاکستری‌ها رو کمی تیره‌تر کنید.
تمامی جاهایی که از فونت light استفاده کردین رو انتخاب کرده و همگی رو ضخیم‌تر کنید.
و …
وقتی غرق در طراحی هستیم، گاهی فراموش می‌کنیم که دیزاین ما ابزاری خواهد بود برای انسان‌ها که بتونن با استفاده از اون، کارهایی رو راحتتر انجام بدن. این فراموشی باعث میشه دیزاین‌هایی رو انجام بدیم که در وهله اول زیبا به نظر برسه ولی وقتی قراره به یک محصول تبدیل بشه، در روند پیاده‌سازی‌ش رفته رفته زیبایی خودش رو از دست بده.

مقالات زیادی برای ایجاد یک نقشه راه (roadmap) برای دیزاین محصولات وجود داره و بسیاری از افراد هم روندی رو که خودشون انجام میدن، با بقیه به اشتراک گذاشتن. ولی به نظر من روند طراحی، از محصولی به محصول دیگه تفاوت‌های جزئی داره که توجه به اون‌ها می‌تونه محصولات رو از سطحی خوب به سطحی عالی ببره.

در این مقاله با آقای Jon Moore همراه می‌شیم تا لیستی از اشتباهاتی رو که دیزاینرها انجام میدن، مرور کنیم. مرور این لیست به ما کمک می‌کنه که روند و نقشه راه دیزاین محصولات با دید بازتری به اشتباهات احتمالی، تعریف کنیم و از تقلید کورکورانه دیزاین‌های انجام شده دوری کنیم.

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

https://medium.com/@jon.moore/fifty-shades-of-fafafa-eaa903e36b9c

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

#طراحی_محصول #اشتباهات_دیزاینرها #معرفی_مقاله
@HamDesign هَم دیزاین

هنگام استفاده از ORM ها در پروژه‌های بزرگ سرعت یکی از عوامل مهم در انتخاب ORM است. غالبا «سرعت» و «امکانات» در مقابل یکدیگر قرار دارند. هر چه به امکانات و قدرت یک ORM اضافه شود از سرعت آن کم می‌شود و بر عکس. البته اکثر ORM های امروز از سرعت قابل قبولی برخوردارند و مقایسه سرعت آنها فقط در داده‌های با حجم زیاد و تناوب بالا مطرح می‌شود. Dapper یکی از Micro ORM های بسیار سریع و مطرح در پلتفرم .net است. این فریم‌ورک بسیار ساده و کوچک نگه داشته شده است و بین برنامه نویسان بسیار محبوب است. جالب است بدانید سایت StackOverflow از این ORM استفاده می‌کند. لینک زیر این Micro ORM را به طور مختصر معرفی کرده و به مقایسه آن با سایر ORM ها پرداخته‌است.

https://www.c-sharpcorner.com/UploadFile/e4e3f7/dapper-king-of-micro-orm-C-Sharp-net/

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

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

___

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

همانند سمت سرور، سمت کلینت نیز storage هایی جهت ذخیره اطلاعات وجود دارد که با توجه به نیاز می توان از آنها استفاده کرد.
از جمله این storage ها، می‌توان به session storage, local storage و cookie اشاره کرد.
دانستن تفاوت بین این سه storage و میزان دسترسی به اطلاعات آنها می‌تواند به انتخاب مناسب در موقعیت‌های متفاوت کمک کند.
باید بدانید که Session storage مربوط به هر تب از browser است بنابراین در تب جدید دیگر وجود ندارد.
و نیز Local storage حافظه‌ای مربوط به browser است، بنابراین اطلاعات مربوط به آن در تمام تب های browser در دسترس خواهد بود و حتی با باز و بسته شدن browser نیز پاک نخواهد شد. اطلاعات موجود در local storage در browser تا زمانی که به طور دستی history مربوط به browser پاک شود یا از طریق جاوا اسکریپت این حافظه خالی شود وجود خواهد داشت.
در انتها Cookie حافظه ای است که مانند local storage عمل می کند با این تفاوت که اطلاعات موجود در cookie از سمت سرور نیز در دسترس بوده و در واقع در سمت سرور می توان از اطلاعات cookie استفاده کرد.
مقاله زیر به طور کامل تفاوت این سه حافظه را ذکر مثال بیان کرده است.

https://www.c-sharpcorner.com/uploadfile/cd7c2e/difference-between-local-storage-session-storage-ans-cookie

#مریم_داودی

لینکدین:
https://www.linkedin.com/in/maryam-davoudi-7913565a

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

___

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

https://www.agilebuddha.com/agile/agile-estimation-8-steps-to-successful-story-point-estimation/

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

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

___

نمونه‌ای جالب و جسورانه از تاثیر «مشاهده» در دیزاین gov.uk

محدودیت‌ها و تعصب‌های ذهنی، یکی از بزرگترین دشمنان دیزاینرها هستند. محدودیت‌های ذهن به ما اجازه نمیدن که خرق عادت کرده و Out of box فکر کنیم، تعصب‌ها بدتر هستن و حتی بعضا اجازه نمیدن که ما چیزی رو که میبینیم، باور کنیم.

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

مقاله امروز یه مقاله گزارشی هست درباره بهبود Radio Buttonها و Checkboxها در سایت gov.uk.
این مقاله از دو جهت به نظرم بسیار بسیار هیجان‌انگیز هست. یک اینکه لزوم انجام بهبودهایی که اشاره میشه از طریق مشاهده کار کاربران بوده، و دو اینکه احتمالا دیزاین نهایی به سلیقه بسیاری از ماها خوش نمیاد ولی بسیار کاربردی هست.
در این مقاله مشاهده‌ای برای نحوه برخورد کاربران هنگام مواجهه با Radio Buttonها و Checkboxها انجام شده و متوجه شدند که کاربران برای انتخاب یک گزینه در یک لیست، بصورت ناخودآگاه به جای کلیک روی متن اون گزینه، اصرار دارند که روی Radio Button یا Checkbox کوچکی که در اول سطر قرار داره کلیک کنند.

دیزاینرهای پروژه، در دیزاین قبلی‌شون، با در نظر گرفتن قانون Fitts، متن گزینه‌ها رو هم قابل کلیک کرده بودند. اون‌ها حتی کادری دور گزینه‌ها قرار داده بودند که بصورت ضمنی، ناحیه قابل کلیک رو مشخص می‌کرد. با این حال باز هم کاربران به کلیک روی Radio Button یا Checkbox علاقه بیشتری نشون می‌دادند.
جالبه نه؟ پیش‌فرض‌های ذهنی ما دیزاینرها تاثیر بسیار زیادی در تجربه کاربران از سرویس ما و در نتیجه میزان موفق سرویس داره.

پیشنهاد می‌کنم برای مطالعه بیشتر این بحث و البته دیدن دیزاینی که دیزاینرهای gov.uk بعد از مشاهداتشون بهش رسیدن، به لینک زیر برید.
کامنت‌های زیر پست هم برای مطالعه پیشنهاد میشه. :)

پ. ن.
قانون Fitts بصورت خلاصه میگه سرعت دسترسی به یک آیتم، تابعی هست از فاصله از اون آیتم و اندازه آیتم.

https://designnotes.blog.gov.uk/2016/11/30/weve-updated-the-radios-and-checkboxes-on-gov-uk/

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

#تجربه_کاربری #گزارش
@HamDesign هَم دیزاین

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

۱. اشتباهاتی که همه ما دیزاینرها انجام می‌دهیم (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/598

۲. معرفی Dapper به عنوان یک Micro ORM
#orm #dapper
https://telegram.me/SoftwarePhilosophy/599

۳. معرفی و مقایسه session storage، local storage و cookie
#clientstorage
https://telegram.me/SoftwarePhilosophy/601

۴. قدم‌های مناسب برای رسیدن به تخمین موفق در پروژه
#estimate
https://telegram.me/SoftwarePhilosophy/602

۵. نمونه‌ای جسورانه از تاثیر مشاهده در دیزاین (هم دیزاین)
#design
https://telegram.me/SoftwarePhilosophy/603

ـــــــــــ
@SoftwarePhilosophy

مدل اسپاتیفای را کپی نکنید

همیشه یاد گرفتن نحوه کار شرکت های معروف هیجان برانگیز است، اینکه آنها چگونه کار می کنند و چگونه محصول تولید می کنند، مدیریت به چه شکلی است? و ...
یکی از این شرکت های معروف که چابک کار می کند اسپاتیفای است، که مدل کار خود را منتشر کرده اند و بسیار مورد استقبال قرار گرفته است. اما اتفاقی که روی داد کپی بدون فکر همین مدل در شرکت های دیگر بوده است،
به یاد داشته باشیم که ⬇️⬇️
همه مدل ها بد هستند ولی بعضی از آنها کار می کنند

@iranagile
@Iranagile

☑️☑️☑️
https://www.infoq.com/news/2016/10/no-spotify-model

الگوی Async Retry Pattern یکی از الگوهایی است که در برنامه‌نویسی برنامه‌های نسل جدید بسیار مهم است. بسیاری دستگاه‌ها و بسترهای جدید شبکه مطمئنی ندارند. برای مثال اینترنت روی گوشی ممکن است بسته به موقعیت قطع و وصل شود و یا کیفیت پایینی داشته باشد. در این بسترها عملیات باید در صورت ناموفق بودن چند بار تکرار شوند و یا اصلاحا retry شود. ابزارهایی که برای retry طراحی شده‌اند این امکان را می‌دهند تا بتوان یک کار را با چند بار retry کردن انجام داد. برای مثال:
var maxRetryAttempts = 3;
var pauseBetweenFailures = TimeSpan.FromSeconds(2);

RetryHelper.RetryOnException(
maxRetryAttempts,
pauseBetweenFailures,
() => {
httpClient.Delete("https://example.com/api/products/1");
}
);

کد بالا برای شرایط کدهای همگام مناسب است ولی اگر بخواهید این کد را به صورت async اجرا کنید و از httpClient.DeleteAsync() استفاده کنید کد مناسبی نیست.

مقاله زیر ضمن تشریح این الگو، توضیح داده‌است که چطور می‌توان با استفاده از async/await الگوی retry pattern را پیاده‌سازی کرد.

https://alastaircrabtree.com/implementing-the-retry-pattern-for-async-tasks-in-c/

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

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

___