💬 از git gc برای حذف فایل های غیر ضروری و فشرده سازی فایل های مخزن git استفاده میشه (توییت مرتبط)

☕️ @airaniTips

💯 تلاش کنید و شکست بخورید، اما در تلاش کردن شکست نخورید.

☕️ @airaniTips

پروتکل HTTP/2 چیست و چه تفاوت‌هایی با HTTP/1 دارد؟

💬 اگر هنوز درباره تغییرات HTTP/2 مطالعه نکردید پیشنهاد میکنم این مقاله مختصر و مفید رو مطالعه کنید. https://goo.gl/3sNNM5

☕️ @airaniTips

انجام کارها به روش انسان غارنشین

ما همیشه سعی می‌کنیم شروع کارها رو تا جایی که می‌شه عقب بندازیم. یه دقیقه بعد، یه ساعت بعد، تا رند شدن ساعت روی عدد ۱۲، تا بعد از خوردن چایی‌ای که تازه دم کردیم… تا اینکه متوجه می‌شیم که خورشید داره غروب می‌کنه و برای ادامه‌ی کار کم‌کم باید چراغ‌ها رو روشن کنیم. کم‌کم شب به نیمه‌هاش می‌رسه و ما با امید اینکه فردا روز دیگه‌ای هست و دیگه فردا کارا رو انجام می‌دیم، چشمامون رو روی هم می‌ذاریم.

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

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

💬 متنی که در بالا مطالعه کردید بخشی از یک مقاله به قلم آقای آرش میلانی بود که می‌توانید متن کامل رو در وبلاگ شخصی ایشون مطالعه کنید. https://goo.gl/8F34Xl
☕️ @airaniTips

نقشه راه دولوپر شدن در سال 2017
 
💬 اینجا در ادامه تصویر زیر چند تا اینفوگرافیک دیگه هست که در واقع ادامه ۳ نقطه های تصویر زیره و به صورت اینفوگرافی خیلی ساده و زیبا ملزومات وب دولوپر شدن در سال ۲۰۱۷ رو در هر کدوم از شاخه های Backend, Frontend, DevOps نشون داده. پیشنهاد می‌کنم از دست ندین

☕️ @airaniTips

۱۰ گام برای مبدل‌ شدن به یک برنامه‌نویس چابک (لینک مقاله)

☕️ @airaniTips

همه دیزاینر هستند!
با این موضوع کنار بیایید

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

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

بعد از کمی فکر، راه حل رو پیدا کردم! جلساتی رو با نام App Review Session شروع کردم و هر هفته اپلیکیشنی ایرانی رو به همه معرفی کرده و ازشون میخواستم روز چهارشنبه ساعت ۴ تا ۵ جمع بشیم و از تجربه کارمون با اون اپلیکیشن بگیم.
خلاصه اینکه امروز بیست و سومین جلسه App Review ما برگزار میشه و نظرات بسیار بسیار تخصصی‌تر شده و همه یک «دیزاینر درون» پیدا کردن.

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

پیشنهاد می‌کنم باقی مطلب بینظیر ایشون رو از زبان خودش بخونید و ازش لذت ببرید.

https://library.gv.com/everyone-is-a-designer-get-over-it-501cc9a2f434

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

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

___

معرفی Prepack: ابزاری جهت اجرای سریع‌تر کدهای جاوااسکریپت
 
💬 ابزار جاوااسکریپتی جدیدی به نام Prepack به تازگی توسط فیس‌بوک جهت بهینه سازی و افزایش سرعت اجرای کدهای جاوااسکریپت معرفی شده. اینجا می‌تونید مقاله ای که در سایت سکان آکادمی درباره این ابزار جدید منتشر شده رو مطالعه کنید.

☕️ @airaniTips

۳۵ عادت بد برنامه‌نویسان که باید ترکشان کنیم

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

☕️ @airaniTips

قانون YAGNI برای ما ها یعنی تا زمانی که بهش احتیاج پیدا نکردی کدش رو ننویس

به عبارت دیگه: منابعت رو برای چیزی که «ممکنه» بهش احتیاج پیدا کنی هدر نده

☕️ @airaniTips

برای دولوپرها: حواستان باشد که در دام این ۱۴ اشتباه نیفتید!

۱. به‌جای این‌که کد بزنید، فقط مشغول مطالعه در مورد کدنویسی هستید
۲. جوری کدنویسی را یاد می‌گیرید که گویا قرار است امتحان بدهید
۳. با بررسی نکردن عملکرد کدهای خود، کوهی از مشکلات را روی هم تلنبار می‌کنید
۴. سعی دارید در انزوا کدنویسی را یاد بگیرید
۵. خیلی زود از کوره در می‌روید
۶. فکر می‌کنید برای این‌که کدنویسی یاد بگیرید نیاز به امکانات خاصی دارید
۷. تفاوت میان حروف بزرگ و کوچک را نادیده می‌گیرید
۸. با روش نادرستی درخواست کمک می‌کنید
۹. فکر می‌کنید برای موفقیت در برنامه‌نویسی حتماً باید نابغهٔ ریاضیات باشید
۱۰. از تغییر دادن کدهای بد خود روی‌گردان هستید
۱۱. فقط به تایپ کردن کدها فکر می‌کنید
۱۲. می‌خواهید همه‌چیز را به یک‌باره بیاموزید
۱۳. انتظار دارید روزی برسد که همه‌چیز را در مورد برنامه‌نویسی بدانید
۱۴. زود ناامید می‌شوید و به راه خود ادامه نمی‌دهید

💬 اگر علاقه داشتید تا شرح موارد بالا رو مطالعه کنید این مقاله رو مطالعه کنید.
https://sokanacademy.com/blog/2103/post

☕️ @airaniTips

تجربه من از کار با Dropbox Paper

الآن حدودا چند ماهی میشه که یادداشت ها و مستنداتم رو روی دراپ باکس پیپر مینویسم دیگه، بعد از تست کردن تقریبا بیشتر ابزارهای معروف مثل گوگل داکز، Evernote و گوگل کیپ و Onenote و … توی دوره های مختلف.

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

دراپ باکس پیپر خیلی نکات مثبت دیگه هم داره که من نگفتم و بقیه چیز های خوبش رو خودتون برید امتحان کنید و لذتش رو ببرید.

پ.ن: بالاخره بعد از مدت ها به بهانه این یادداشت وبلاگم رو هم به‌روز کردم 😊
http://p30design.net/1396/04/dropbox-paper-experiance.html

☕️ @airaniTips

احتیاج کاربر را طراحی کنید،
نه درخواست او را!

قطعا هیچ سرویسی بدون گرفتن بازخورد (Feedback) کاربران نمیفهمه که آیا در حال حرکت در مسیر درست رفع نیاز کاربر هست یا نه.
ولی در بسیاری از مواقع، سرویس‌ها ایمیل و تماس‌هایی از کاربران دریافت می‌کنن که بصورت مستقیم خواستار ایجاد بخش جدید در سرویس هستند.
سوال مهم اینجاست که آیا باید درخواست کاربر را اجرا کرد یا نه؟
به تجربه شخصی من، مشابه این موضوع هنگام کار با کارفرماهای مختلف پیش میاد. درخواست‌هایی مثل تغییر رنگ یک بخش خاص در طراحی، به رنگی دیگر و یا اضافه کردن یک دکمه خاص در صفحه‌ای از اپلیکیشن. بسیاری از طراحان محصول به این صورت عمل می‌کنند که درخواست‌ها را عینا به شکل مطرح شده اجرا می‌کنند. این کار در اغلب موارد منجر به از دست رفتن یکپارچگی طراحی ظاهری و یا طراحی امکانات محصول میشه.
آقای Michael Sueoka، سرپرست تیم طراحی تجربه‌کاربری سرویس The Mobile Majority، با مطرح کردن این موضوع و بررسی تبعات مخرب اجرای مستقیم درخواست‌های کاربر، راه حلی ارائه میدن که به نظرم باید بخش جدایی‌ناپذیری از پروسه طراحی یک محصول باشه.
ایشون با عنوان این که کاربر معمولا نمیدونه که به چه چیزی احتیاج داره و فقط می‌دونه که چه چیزی رو می‌خواد، تفاوت این دو حالت رو مثال کودکی دونستن که برای یک وعده اصلی غذایی، مقدار زیادی شکلات طلب می‌کنه.
در مقابل درخواست‌های این چنینی کاربران، راه حل Michael خوندنی هست.

http://blog.invisionapp.com/dont-design-what-users-want/

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

#طراحی_محصول #بازخورد
@HamDesign هَم دیزاین

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

اگر نمی توانی به چیزی گوش کنی، هرگز نمی توانی به کسی دستور بدهی.

مراقب باش که هنگام طراحی برنامه ها دورت شلوغ می شود و همه اظهار نظر می کنند، اما هنگام اجرا و تحقق برنامه ها کسی کنارت نیست و تنها می مانی، پس برنامه هایت را طوری طراحی کن که اگر تنهایت گذاشتند، بتوانی خودت آن را به پیش ببری و پشیمان نشوی که هیچ راه برگشتی وجود نخواهد داشت.
http://abolfazl.me/?p=5089

☕️ @airaniTips

یاد بگیریم بگیم: «نمی‌دونم»

سقراط: «من عاقل ترین مرد زنده هستم، برای اینکه یک چیز رو می‌دونم و اون اینه که من هیچی نمی‌دونم.»
https://goo.gl/z5EFF6

☕️ @airaniTips