درباره Titanها بیشتر بدانیم!

چطور می‌شود که تایتان‌ها انقدر قوی باشند؟ اگر در جریان سری کامیک‌ها و فیلم‌های Marvel باشید می‌دانید که اخیرا جنگی به نام Infinity War در دنیای Marvel به راه افتاده است. یک طرف این جنگ Thanos، از نژاد تایتان‌ها قرار دارد و در طرف دیگر آن، Capitan America، Iron Man و Thor و حتی Hulk و باقی Avengers! و با این‌حال نگران هستند که مبارزه را واگذار کرده و این اتفاق، نقطه پایانی باشد برای نسل تمام موجودات زنده در دنیا.

برای اطلاع بیشترتان می‌خواهم چند ویژگی تایتان‌ها را نام ببرم: ذهن و پوستی غیرقابل نفوذ؛ قدرت،‌ سرعت و استقامتی منحصربفرد؛ کنترل انرژی؛ نامیرا بودن و …
هیجان‌انگیزست نه؟ گذشته از توضیحات دنیای Marvel که دلیل قدرت تایتان‌ها را ترکیب شدن ژن جاودانی، تکثیر بیونیک، قدرت‌های خدایی و نهاد مرگ می‌داند، تایتان‌های دنیای واقعی چه کسانی هستند؟ چگونه دیزاینرها هم می‌توانند درون خود تایتانی داشته باشند؟

آقای Tim Ferriss، یکی از سرمایه‌گذاران موفق دنیای استارتاپ‌ها، کتابی درباره موفق‌ترین و قدرتمند‌ترین انسان‌های دنیای واقعی با نام «ابزارهای تایتان‌ها» یا Tools of Titans منتشر کرده‌ست. Tim در یادداشتی، از تجربیاتش در برخورد با این انسان‌های فوق موفق نوشته‌ست که پست امروز ماست.
جدای از اینکه خواندن کتاب ایشان را شدیدا پیشنهاد می‌کنم، مقاله امروز به کلیدی‌ترین ویژگی تمامی این افراد اشاره دارد و آن «ورزش و تمرین ذهن» است.

می‌پرسید دقیقا چگونه؟ مقاله امروز را از دست ندهید:

https://medium.com/the-mission/the-one-routine-common-to-billionaires-icons-and-world-class-performers-28ed11a49eda

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

پ. ن.
تریلر فیلم Avengers: Infinity War، محصولی از کمپانی Marvel:
https://www.youtube.com/watch?v=I0e3TXkSd4Q

#بررسی #ابزار_تایتان #موفقیت_خلاقیت
@Dexign فلسفه دیزاین

___

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

اضافه کردن فیچر به نرم‌افزار غالبا ویژگی مثبتی به نظر می‌رسد. ولی وقتی تیمی دارید که قدرت بسیار بالایی دارد اضافه کردن فیچرها با سرعت خیلی زیاد خودش می‌تواند نکات منفی داشته باشد. وقتی قدرت اضافه کردن امکانات با سرعت زیاد دارید باید محتاط باشید که امکانات جدید راه‌حل‌هایی جدید برای یک مسئله حل شده نباشند. داشتن تیم قدرتمند این قدرت را به مدیران می‌دهد که بتوانند سریع ایده‌های ذهنی خود را پیاده‌سازی کنند. در این حین باید مراقب بود این امکانات با هم، همپوشانی نداشته باشند.
مثال زیر از تیم توسعه C# آورده شده‌است که در مورد کاربرد دو امکان این زبان که در نسخه‌های ۵ و ۶ اضافه شد صحبت می‌کند.

http://mehrandvd.me/2016/05/02/steady-consistent-flow-features/

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

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



___

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

اصطلاح Full Stack Developer عبارتی است که در چند سال اخیر بسیار رایج شده‌است. این برنامه‌نویسان معمولا درک خوبی از برنامه‌نویسی، زیرساخت، طراحی و حتی فهم بیزنس‌ها دارند. چند سالی هم هست که «متخصص UX» به عنوان یک تخصص مهم در تیم‌ها جا افتاده است. مقاله زیر اصطلاح جدیدی را با عنوان Full Stack UXer را معرفی می‌کند و نشان می‌دهد که این نقش و تخصص در یک تیم چقدر می‌تواند به موفقیت کمک کند. در این مقاله تخصص‌هایی که از یک Full Stack UXer انتظار می‌رود توضیح داده شده است. در این تعریف معمولا این فرد بیشتر درگیر تخصص‌های زیادی خواهد بود که از Gamification تا حتی برنامه‌نویسی را شامل می‌شود.

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

http://uxmag.com/articles/the-full-stack-uxer

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

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



___

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

نوشتن یک رزومه خوب برای پست‌های برنامه‌نویسی و یا UI/UX بسیار مهم است. رزومه باید بتواند قابلیت‌های شما را در یک تعامل ذهنی به خواننده منتقل کند. شما باید بتوانید در رزومه خود، یک خط پنهان طراحی کنید تا کسی که رزومه شما را می‌خواند ناخودآگاه به ترتیبی که شما می‌خواهید رزومه شما را ببیند. به عبارت دیگر، اگر برای پست UI/UX رزومه می‌نویسید باید در آن اصول UI/UX را رعایت کنید.

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

http://www.rleonardi.com/interactive-resume

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

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



___

چهار موردی که کاربران بخاطرشان از شما متنفرند!

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

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

در مقاله امروز به نقل از سرویس طراحی Justinmind به بررسی نتایج بدست آمده در این نظرسنجی می‌پردازیم.

مقاله امروز را از دست ندهید:

https://uxplanet.org/what-users-hate-most-about-your-app-according-to-google-c4a089ddfafa

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

#بررسی #نظرسنجی #مشکلات_اپلیکیشن
@Dexign فلسفه دیزاین

___

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

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

http://www.c-sharpcorner.com/article/managing-technical-debt-using-vsts

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

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



___

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

۱. اضافه کردن فیچر به نرم‌افزار مزایا و معایب

https://t.me/SoftwarePhilosophy/1285

۲. Full Stack Developer کیست؟

https://t.me/SoftwarePhilosophy/1287

۳. اهمیت نوشتن رزومه خوب برای پست‌های برنامه‌نویسی و یا UI/UX

https://t.me/SoftwarePhilosophy/1289

۴. چهار موردی که کاربران بخاطرشان از شما متنفرند! (فلسفه دیزاین)

https://t.me/SoftwarePhilosophy/1290

۵. آشنایی با مفهوم Technical Debt یا «بدهی فنی»

https://t.me/SoftwarePhilosophy/1292

ـــــــــــ

@SoftwarePhilosophy

💡 هکَتان ایننوتکس ۲۰۱۸

هکَتان اینوتکس یک مسابقه سراسری برای تمامی ایده پردازان، توسعه‌دهندگان و طراحانی است که ایده‌ای برای بهتر شدن تجربه زندگی شهری و یا حل مشکلات شهری دارند. با شرکت در این هَکَتان و ثبت ایده خود فرصتی برای ارائه و گسترش ایده‌های خود با حمایت نهادهای دست اندرکار مسابقه خواهید داشت.
این هَکَتان محدود به یک زبان برنامه نویسی خاص و یا به طور کلی برنامه نویسی نیست! بلکه شما می‌توانید حتی با ارائه ایده و طرح خود نیز در این مسابقه شرکت نماييد.

ثبت نام از 👇
hack.inotex.com

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

http://ow.ly/vxkT30kDcxb

#امیررضا_محمدی (http://ow.ly/I0YC30kDclv)

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


___

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

عبارت Transpiler این روزها در دنیای مدرن برنامه‌نویسی زیاد استفاده می‌شود. عمل Transpiling در حقیقت تبدیل یک کد از یک زبان به یک زبان هم سطح دیگر است.
این در حالی است که مفهوم Compiling یک مفهوم کلی‌تر است و به معنی تبدیل یک زبان به هر چیز دیگری (مثل یک زبان نزدیک به ماشین یا زبان هم‌سطح) است. برای مثال عمل تبدیل یک کد TypeScript به JavaScript توسط یک Transpiler‌ انجام می‌شود. زیرا این دو زبان از لحاظ سطح انتزاع شبیه هم هستند. ولی عمل تبدیل کد C# به IL یا تبدیل کد C++ به binary code و یا تبدیل Java به byte code یک کامپایل محسوب می‌شود. زیرا این تبدیل به یک زبان نزدیک به ماشین است.
در لینک زیر می‌توانید این مفاهیم را با جزئیات بیشتری مطالعه کنید.

https://www.stevefenton.co.uk/2012/11/compiling-vs-transpiling

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

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


___

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

هرم شیطان یا Pyramid of Doom یک مشکل معروف در دنیای برنامه‌نویسی است. این مشکل معمولا وقتی پیش می‌آید که برنامه‌نویس مجبور است تعداد زیادی if تو در تو بنویسد، در این صورت با رعایت تو رفتگی‌های کد، کد شما از دور یک هرم خیلی بزرگ به نظر می‌رسد. یک نمونه متداول چک کردن مقادیر null به وسیله if های تو در تو است. این هرم هنگام استفاده از callback های متوالی نیز پیش می‌آید. در برنامه نویسی به زبان JavaScript حتما این هرم را در کدها دیده‌اید. لینک زیر نحوه تشکیل این هرم در کد را نشان می‌دهد و برای رفع آن در برخی حالت‌ها راه حل هایی ارائه داده است.

https://en.wikipedia.org/wiki/Pyramid_of_doom_(programming)

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

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


___

‍ سومین رویداد دورهمی برنامه نویسان تهران (موضوع : DevOps)

لینک ثبت نام:
https://evnd.co/BXWEr
زمان : پنج شنبه ۷ تیر، ساعت 16:00 تا 19:00
مکان : تهران خيابان وليعصر، بالاتر از ونك، خيابان عطار، نرسيده به ميدان عطار، مجموعه ورزشی فرهنگی ونک

خیلی هامون واژه DevOps رو شنیدیم ولی نمیدونیم چیه؟ خیلی هامون فقط در حد ابتدایی از طریق مقالات و سایت ها باهاش اشنا شدیم، بعضی هامون هم باهاش در ارتباط بودیم ولی درک صحیح و کاملی ازش نداریم و یا به صورت عملی باهاش دست و پنجه نرم نکردیم.
توی این رویداد میخوایم تفکر DevOps ، وظایف عملیاتی و ابزار های اون رو مورد بررسی قرار بدیم اونم نه صرفا به صورت تئوری، بلکه بیشتر به صورت عملی و کاربردی.

اگه شما هم
1- موقع انتشار نسخه های جدید نرم افزارتون دچار ترس و نگرانی هستید که مبادا پروژه دچار مشل بشه
2- به دنبال یه روش اصولی و مکانیزه برای چرخه انتشار و استقرار نرم افزارتون هستید
3- میخواین از قابلیت های برنامه های ورژن کنترول نظیر git و tfs به صورت صحیح و کامل استفاده کنین
4- احساس میکنین به DevOps نیاز دارین و یا تصورات اشتباه و ناقصی از این واژه دارین
پس پیشنهاد میکنیم این رویداد رو از دست ندین.

رویداد دورهمی برنامه نویسان تهران چیه؟
رویداد دورهمی برنامه نویسان تهران فرصتی است که در آن ضمن آشنایی با یکدیگر و شبکه سازی، به بحث تبادل نظر و یادگیری درباره موضوعات مختلف برنامه نویسی می پردازیم.

مواردی به اون ها میپردازیم :
۱- اصلا DevOps چی هست و چه فایده ای برای ما داره؟
۲- تشریح وظایف DevOps
۳- یکپارچه سازی فرایند توسعه و انتشار
۴- استفاده اصولی و کامل از قابلیت های سیستم های ورژن کنترل نظیر git (استفاده مناسب از ‌Git Branching به همراه مدیریت Feature ها، Planning و همچنین مدیریت Task ها، Bug ها و ... رو به صورت اصولی و کاربردی)
۵- تشریح و پیاده سازی Continues Integration و Continues Delivery
6- تشریح تست خودکار (Automaion Test)
7- تشریح Release pipline و استفاده از Docker در آن

البته DevOps در کنار خودش دو بحث حیاتی تست خودکار و Docker رو داره که در مورد Docker قبلا ارائه ای داشتیم، و در مورد تست خودکار ارائه ای مجزا و کامل خواهیم داشت. آن چه که در این ارائه بیشتر بهش خواهیم پرداخت تجربه مون در راه اندازی Release Pipeline برای iOS، چگونگی ارتباط دادن کار-کد-تست-اشکال و رفع اشکال و نسخه به یکدیگه و کلی موارد کاربردی دیگه است.

میزبان این جلسه : مجموعه ورزشی ونک
حامی رسانه ای : اوکس تیم

از این که با حضوتون، بار علمی رویداد رو افزایش میدهید سپاسگذاریم.

لینک ثبت نام:
https://evnd.co/BXWEr

این رویداد در مورد مباحث DevOps است. من هم در مورد موضوعاتی مرتبط با پست‌های زیر از بلاگ شخصیم صحبت خواهم کرد.

- http://mehrandvd.me/2017/02/24/azure-experience-handling-requirements/
- http://mehrandvd.me/2015/09/06/be-a-developer-not-a-programmer/
- http://mehrandvd.me/2017/08/02/effort-vs-time-estimation/

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

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


___

همیشه بهانه‌ای برای انجام ندادن user research هست!

یکی از عواملی که باعث محبوبیت و موفقیت محصول شما می‌شود، user research است. در این فرایند تمرکز بر فهمیدن رفتار کاربران، نیازهای واقعیشان و انگیزه‌های آنهاست.

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

۱. ما همین الان هم کاربرانمون رو می‌شناسیم: موضوع شناختن کاربران نیست، بلکه موضوع شناختن این است که آنها چطور فکر می‌کنند، چطور رفتار می‌کنند و در برابر محصول ما چه احساسی دارند.

۲. ما یک usability test lab نداریم: متاسفم که باید بگم شما نیازی ندارید! این فقط یکی از راه‌های تحقیق کاربری هست. راه‌های خیلی زیاد و مختلف دیگری نیز وجود دارد.

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

۴. بودجه کافی نداریم: کوچک شروع کنید. حتی یک تحقیق غیر رسمی با یکی دو نفر خیلی بهتر از انجام ندادن آن است.


لیست کامل این بهانه‌ها و توضیحات آنها را می‌توانید در بلاگ زیر بخوانید.

https://uxdesign.cc/most-common-excuses-for-not-doing-user-research-6c7eec5076ee

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

http://ow.ly/Oy5v30kGKR1

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

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


___

دیزاین‌های غیرقابل یادگیری:
راهنمای جامع آزار کاربران

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

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

حتما برای شما هم پیش‌آمده که یک اشتباه ثابت را در یک اپلیکیشن/وب‌سایت یا حتی محصولات فیزیکی، بارها و بارها تکرار کنید. یکی از بارز‌ترین دلیل‌های این نوع اشتباهات این است که دیزاینر محصول، درک و عادت‌های کاربر را در نظر نگرفته‌ست.

امروز در یک مقاله بسیار جذاب با مثال‌های کاربردی مختلف به بررسی دیزاین‌های آزاردهنده می‌پردازیم تا با یادگیری آن‌ها، بتوانیم محصولی بهتر برای کاربران دیزاین کنیم.
مقاله امروز را از دست ندهید:

https://medium.com/@cwodtke/the-intuitive-and-the-unlearnable-cccffd9a762

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

#اشتباهات #طراحی_محصول #تجربه_کاربری
@Dexign فلسفه دیزاین

___

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

۱. هکَتان ایننوتکس ۲۰۱۸

https://t.me/SoftwarePhilosophy/1294

۲. آشنایی با مفاهیم Transpiling و Compiling

https://t.me/SoftwarePhilosophy/1296

۳. هرم شیطان یا Pyramid of Doom چیست؟

https://t.me/SoftwarePhilosophy/1298

۴. همیشه بهانه‌ای برای انجام ندادن user research هست!

https://t.me/SoftwarePhilosophy/1301

۵. دیزاین‌های غیرقابل یادگیری: راهنمای جامع آزار کاربران (فلسفه دیزاین)