یکی از مشکلاتی که همیشه برنامه نویسان موبایل با آن درگیر بوده اند بروز رسانی نرم افزارهای موبایل می‌باشد. هر بروز رسانی نرم افزار نیاز به طی شدن مراحل تایید App Store ها دارد که این امر در بروز رسانی نرم افزارها تاخیر ایجاد می‌کند و امکان رفع سریع مسایل نرم افزار را به تولید کنندگان نمی‌دهد. Code Push سرویسی ابری است که مایکروسافت ارائه می‌دهد تا با آن نرم افزارهای موبایل نصب شده برای کاربران بدون نیاز به طی شدن این مراحل بروزرسانی شود. این سرویس برای نرم افزارهای موبایل مبتنی بر React Native و Cordova طراحی شده است که در آن بخش HTML و JavaScript نرم افزار به لحظه بروزرسانی می‌شود.

https://github.com/Microsoft/code-push

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

https://ow.ly/eMUV30ghdrj

#علیرضا_وفی (https://ow.ly/Vna930dsUGr)


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

___

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

فیسبوک علاوه بر توسعه React برای وب و موبایل قدم به حوزه‌ی دیگری نیز نهاده است. با استفاده از React VR می‌توان با استفاده از جاوا اسکریپت نرم افزارهای واقعیت مجازی تولیدی نمود.

https://facebook.github.io/react-vr

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

https://ow.ly/sjGB30gAX3w

#علیرضا_وفی (https://ow.ly/Vna930dsUGr)


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


___

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

برنامه‌نویسان NASA یکی از چالشی‌ترین کارهای برنامه‌نویسی در جهان را دارند. عمده برنامه‌هایی که آنها می‌نویسند بسیار حساس و اصطلاحا Mission Critical هستند.
برنامه‌هایی که در ناسا نوشته می‌شوند نباید هیچ خطایی داشته باشند. کوچکترین خطا در برنامه باعث نابود شدن کل پروژه می‌شود (برای مثال سقوط شاتل یا نرسیدن به مقصد).
به همین دلیل روشی که آنها طبق آن کد نویسی می‌کنند می‌تواند بسیار آموزنده باشد.
در لینک زیر ۱۰ قانون حیاتی که تیم برنامه‌نویسی «آزمایشگاه نیروی متحرکه جت» یا Jet Propolution Labratovary از آن استفاده می‌کنند آمده است.
با اینکه این قوانین عمدتا برای زبان C تدوین شده‌اند ولی بیشتر آنها در همه زبان‌ها کاربرد دارند و خواندن این قوانین می‌تواند بسیار آموزنده باشد.

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

https://fossbytes.com/nasa-coding-programming-rules-critical/


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

https://ow.ly/UkMY30gO6Si

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

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

___

چگونه تمام ستاره‌ها را در یک آسمان جمع کنیم؟

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

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

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

- از یاد گرفتن از افراد Senior استقبال کنید: وجود افراد حرفه‌ای، تیم شما را حرفه‌ای می‌کند. از طرفی استخدام افرادی که Junior هستند، با این هدف که بتوانید آنها را کنترل کنید بزرگترین اشتباه است. یکی از سوالاتی که در مصاحبه‌ها از خودم می‌پرسم این است که «آیا این آدم می‌تونه یه روزی رئیس من بشه؟ آیا من حاضرم تو تیم این شخص کار کنم؟» اگر جواب بله باشد این شخص یک کاندیدای ارزشمند است و می‌تواند ارزش زیادی در تیم خلق کند.

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

https://medium.com/the-year-of-the-looking-glass/managing-more-experienced-people-9893f9903649

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

#بررسی #چالش #مدیریت_تیم

#مهران_داودی

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


____

فریم‌ورک React یکی از فریم‌ورک‌هایی است که محبوبیت بسیار زیادی بین برنامه‌نویسان وب (و موبایل) پیدا کرده‌است. معماری این فریم‌ورک بسیار زیبا، سبک و قابل گسترش است. مفهوم Immutable طوری در این فریم‌ورک دیده شده که به نظر من یکی از مهمترین دلایل تمایز این زیرساخت با سایر زیرساخت‌ها است. هر اکوسیستمی که در community محبوب شود، باید منتظر کتابخانه‌‌های جذابی باشید که توسط برنامه‌نویسان دیگر برای آن ساخته می‌شود.
لینک زیر ۱۰ کتابخانه جذاب روی GitHub را که برای React توسعه داده شده‌اند را معرفی کرده‌است.


https://hackernoon.com/top-10-react-libraries-on-github-ebf730e7ac25


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

https://ow.ly/MX9B30hGWbQ

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

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

___

💢 چگونه حذف ویژگی های اضافی در محصول موجب متمایز بودن آن در بازار می شود؟!

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

👇👇👇👇

🔗 https://goo.gl/Hz7RbN

🆔 @agileproduct

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

۱. سرویسی برای به روز رسانی لحظه‌ای بخش‌های HTML و JavaScript نرم‌افزارهای موبایل

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

۲. استفاده از React VR و جاوا اسکریپت برای تولید نرم افزارهای واقعیت مجازی

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

۳. آشنایی با قانون حیاتی که تیم برنامه‌نویسی «آزمایشگاه نیروی متحرکه جت» ناسا

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

۴. چگونه تمام ستاره‌ها را در یک آسمان جمع کنیم؟ (فلسفه دیزاین)

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

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

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

۶. چگونه حذف ویژگی های اضافی در محصول موجب متمایز بودن آن در بازار می شود؟! (Agile Product Management)

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

ـــــــــــ

@SoftwarePhilosophy

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

عنوان URLs are UI، عنوانی بسیار جذاب برای مقاله جدید scott hanselman است. نکته خیلی جالبی که بسیاری از برنامه‌های امروزی ندارند. او در این مقاله توضیح می‌دهد که خود URL ها به قسمتی از UI برنامه تبدیل شده‌اند و خوانا بودن آن و قابل خواندن بودن آنها بسیار مهم است.
برای مثال لینک یک فایل در OneDrive شبیه
https://onedrive.live.com/?id=CD0633A7367371152C%21172&cid=CD06A73371152C
است. در حالیکه لینک یک فایل مشابه در DropBox شبیه
https://www.dropbox.com/home/Games
است.
در مقاله زیر توضیح داده شده‌است که برای مثال مدلی که در StackOverflow استفاده می‌شود چقدر خوب و خلاقانه است.
https://stackoverflow.com/users/1831530/mehrandvd
در این مدل هم از کد و هم از نام استفاده شده ولی قسمت نام بی‌اثر است و با حذف آن هنوز لینک کار می‌کند.

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

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

https://ow.ly/YHoU30e1jDD

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

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


___

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

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

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

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

https://ow.ly/p03w30cbHdO

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

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


___

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

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

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

https://geekswithblogs.net/mrsteve/archive/2016/12/28/object-mapper-performance-comparison-allowpartiallytrustedcallers.aspx

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

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

___

تکنیک‌های جذاب برای پیش از بارگذاری تصاویر

هیچوقت معرفی شدن HTML5 را فراموش نمی‌کنم، در خوابگاه بالا و پایین می‌پریدم و از پتانسیل‌های آن و نمونه‌هایی که از استفاده‌هایش در اینترنت دیده بودم برای هم اتاقی‌هایم می‌گفتم. آن‌ها هم چون رشته‌های مرتبط با کامپیوتر نداشتند، با نگاهی سرشار از تعجب و «خُب که چی؟» من را نگاه می‌کردند.
از یک جایی به بعد، وب با سرعتی سرسام‌آوری روی به پیشرفت آورد. دریچه‌هایی را به روی تمامی انسان‌های خلاق گشود که سرعت حرکت و وقوع اتفاقات جدید را در آن چند برابر کردند.
مقاله امروز هم درباره یک ایده جدید در وب است.

قبل از شروع صحبت، اجازه بدهید دو مفهوم زیر را برایتان تعریف کنم.
Placeholderها: همان عناصری هستند که تا زمان بارگذاری تصاویر، جای آن‌ها را برایشان نگه‌داشته و کاربرها را سرگرم می‌کنند.
و SVG: پسوند مربوط به تصاویر برداری (Vector) که به دلیل حجم کم و چند ویژگی دیگر، در وب جایگاه بسیار محبوبی پیدا کرده است.
قبل‌ترها از عکس‌های ثابت، رنگ‌ها و اینطور چیز‌ها به عنوان Placeholder استفاده می‌شد، ولی امروزه سرویس‌های مختلف حرکتی را آغاز کردند تا هرچقدر که می‌توانند Placeholder یک تصویر را به خود تصویر نزدیک کنند.
تلاش Google Image Search در این جهت، مرتبط بودن رنگ هر Placeholder به عکسی که بعدا در آن بارگذاری می‌شود، و تلاش Instagram، نمایش یک نسخه تار شده از عکس‌ها قبل از بارگذاری آن‌ها است.

امروز پیشنهاد جذاب و هوشمندانه یکی از برنامه‌نویسان Frontend شرکت Spotify را بررسی می‌کنیم. ایشان می‌گویند: مگر نه اینکه SVGها بسیار کم حجم هستند؟ پس چرا یک نسخه ساده شده بُرداری از تصاویر را قبل از بارگذاری‌شان نمایش ندهیم؟
هیجان‌انگیز است، نه؟
به نظر من که ایده بسیار جذابی‌ست. پیشنهاد می‌کنم جزئیات ایده ایشان را از زبان خودشان بخوانید:

https://medium.freecodecamp.org/using-svg-as-placeholders-more-image-loading-techniques-bed1b810ab2c

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

#معرفی #ایده #طراحی_رابط‌کاربری
@Dexign فلسفه دیزاین

___

🔴 7 روش برای مقابله با جلسات برنامه ریزی خسته کننده


1- با شکم خالی جلسه برگزار نکنید

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

2- قبل از جلسه برنامه ریزی، جلسه باید آماده شده باشد

موضوعاتی که قرار است در جلسه روی آنها صحبت شود باید قبل از جلسه آماده شده باشند، آماده شدن یعنی اینکه، مالک محصول باید بداند که هدف او در اسپرینت بعد چیست؟ چه کارهایی قرار است برای رسیدن به هدف انجام شود (از نظر ویژگی های نرم افزار) در مورد نیازمندی های اسپرینت حتما با مشتری ها یا ذی نفعان صحبت کرده باشد تا دقیقا مشخص شود که نیازمندی چیست؟ (این به معنی این نیست که تا ته پروژه باید همه کارها را در یک روز انجام بدهد، بلکه به مرور و همگام با تیم نیازمندی ها باید شفاف شوند) سعی شود شرایط پذیرش کار تا آنجایی که امکان پذیر هست مکتوب شده باشد و منتظرجلسه نشویم

3- انرژی محدود است پس اولویت بندی لازم است

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

4- تایم باکس باشیم

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

5- ما در طول اسپرینت هم در حال برنامه ریزی هستیم

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

6- Swarm کنید

شاید در طول اسپرینت نیاز به یک کار فکری باشد و این هم نیاز به خرد جمعی باشد، بهترین کار این است که یک جلسه با حضور همه یا بخشی از نفرات تیم برگزار شود، این جلسه نیز باید 1- تایم باکس باشد 2- فقط حول و حوش یک موضوع خاص باشد 3- زمانبدی شروع خوبی داشته باشد

7- جلسه نیاز به تسهیل گر دارد

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

https://goo.gl/Fz9Kb1

@iranagile

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

۱. استاندارد طراحی URL از لحاظ UX

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

۲. امنیت در سیستم‌های large scale با راهکار تیم امنیت بهسازان بانک ملت

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

۳. مقایسه عملکرد فریم‌ورک‌های مشهور Mapper از لحظا سرعت و عملکرد

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

۴. تکنیک‌های جذاب برای پیش از بارگذاری تصاویر (فلسفه دیزاین)

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

۵. هفت روش برای مقابله با جلسات برنامه ریزی خسته کننده (Iran Agile)

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

ـــــــــــ

@SoftwarePhilosophy

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

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

ولی تجربه نشان می‌دهد بیشترین علت «افزونگی کد» برنامه‌نویسان نیستند! بلکه این مشکل بیشتر به خاطر «معماری بد نرم‌افزار» است. معمار نرم‌افزار کسی است که هنگام معماری باید «فضاهای» کد را طوری معماری کند تا احتمال به خطا افتادن برنامه‌نویسان کمتر شود.

لینک زیر توضیح می‌دهد که چگونه یک معماری بد باعث «رشد افزونگی کد» در نرم‌افزار می‌شود.


https://mehrandvd.me/2016/02/28/growing-redundancy-an-architectural-disease/

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


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


___

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