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

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

http://www.cio.com/article/2436015/enterprise-architecture/5-things-grady-booch-has-learned-about-complex-software-systems.html

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

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

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


___

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

دیتابیس‌های NoSQL امروزه در معماری‌های نوین نرم‌افزار جایگاه ویژه‌ای پیدا کرده‌اند. در سال‌های قبل از این نوع دیتابیس‌ها فقط در پروژه‌های خاصی استفاده می‌شد ولی به مرور نقش این نوع دیتابیس‌ها با ظهورمعماری‌های نوین یا مفاهیمی مانند CQRS پر رنگ تر شده‌است. مفاهیم این دیتابیس‌ها به طور کلی با مدل فکری دیتابیس‌های رابطه‌ای یا Relational متفاوت است.

http://www.c-sharpcorner.com/article/introduction-to-no-sql-and-working-with-mongodb-part-one/

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

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


___

🔵 هرچیز مهم به ندرت فوریت دارد و هر چیز فوری به ندرت مهم است

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

یک مالک محصول خوب باید بتواند در اولویت بندی کارها هم فوریت و هم اهمیت کارها را در نظر بگیرد.

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

http://bit.ly/2JOKK82
@iranagile

درباره 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


___