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

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

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

برخلاف گروه B، افراد گروه A بجای اینکه بخوان تلاش کنند و سفال بسازن، کل ترم رو درگیر مسائل تئوری بودن که چطور میشه بهترین سفال ممکن رو ساخت! در نهایت چون شبیه افراد گروه B نتونستن ساخت سفال رو خیلی تمرین کنن، نتونستن سفال عالی که در ذهنشون بوده رو در واقعیت بسازن.

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

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

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

۲- جذب کارآموز: تقریبا از هر ۵ تا درخواست استخدام حدود ۴تاشون نیروی کار متخصص میخوان، و از هر ۵ نفر جویای کار، حدود ۳ نفر دنبال کارآموزی هستند. در نتیجه خیلیا همین اول راه گیر می‌کنند و با اینکه علاقه دارن ولی جایی رو برای رشد کردن پیدا نمی‌کنند. تازه بماند که بعضی از شرکت‌ها هم نمیدونن کارآموز چیه! فکر می‌کنند کل قضیه اینه که یکی رو استخدام کنند که چیزی بلد نیس و بهش فشار بیارن تا یه پروژه‌ی سخت رو به تنهایی تموم کنه. بعد تازه پیش خودشون حس می‌کنند کلی به اون برنامه‌نویس لطف می‌کنند و خودشونم از سرمایه‌گذاری که در جذب کارآموز کردن به سود رسیدن. البته این ایده معمولا نتیجه برعکس میده، یعنی نه تنها اون برنامه‌نویس دانش عمیقی یاد نمیگیره، حتی اون پروژه رو هم که زده، احتمالا باید از اول نوشت.

 

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

پ.ن۲: قطعا منظورم ۱۰۰درصد شرکت‌ها نیست، بعضی شرکت‌ها به این موارد اهمیت میدن. البته بیشتر به مورد ۲ اهمیت میدن، کمتر شرکتی رو دیدم که درگیر مورد ۱ باشه.

پ.ن۳: من متخصص منابع انسانی نیستم، بیشتر به عنوان یه برنامه‌نویس که خودش دوست داره تخصص بیشتری داشته باشه نظرمو نوشتم.

خیلی وقت بود که دوست داشتم روی اپ‌های ماژولار کار کنم، این دوست داشتن مقدمه‌ی یه هفته‌ای مطالعه و تست بود که در نهایت خروجیش تبدیل به ریپوی AndroidModularization توی گیت‌هاب شد. در کنار هدف اصلی (اپ ماژولار) یه هدف فرعی هم داشتم که یه نمونه کد authentication با قابلیت رفرش شدن توکن برای وب‌سرویس moviesapi.ir درست کنم. اگر بخوام خلاصش کنم میشه این پروژه یه اپ ماژولار هست که از قابلیت‌های وب‌سرویس moviesapi.ir استفاده میکنه.

توی توسعه این پروژه از کتابخونه‌هایی مثل Rxjava ,Dagger2 ,Retrofit, Room , Databinding و … استفاده شده ولی تمرکز اصلی روی ساخت اپ ماژولار با استفاده از Dagger2 بوده. یعنی اگر میخواید RxJava یاد بگیرید، توی این پروژه نباید دنبال Best Practiceهاش باشید.

ادامه …

روزی که جنریتور “حلما” رو درست کردم، تصمیم گرفتم Open Sourceش کنم. چون اولین بار بود که میخواستم اینکارو بکنم، هیچ ایده‌ای نداشتم که از کجا باید شروع کرد یا باید به چه نکاتی توجه کنم. به همین دلیل، پیش یکی از بهترین دوستام به اسم گوگل!! رفتم تا مثل همیشه کمکم کنه، توی گوگل با کلیدواژه‌های start، open source و how جستجو کردم. بیشتر مقاله‌هایی که آورد رو خوندم، یه تعدادیشون نکته‌های خیلی خوب داشتند، این نکته‌هارو توی Evernote نوشتم تا سرفرصت تبدیلشون کنم به این مقاله‌ای که الان میخونید. ادامه …

هر موقع در مورد اینکه توی شرکت‌های خوب خارجی TDD کار میکنند صحبت میشد، پیش خودم میگفتم که خب توی ایران با توجه به ددلاین‌های پروژه، اخلاق کارفرما و … نمیشه مثل اونا بود وگرنه منم حتما TDD کار میکردم. برای خودم تست ننوشتن رو همینجوری توجیه میکردم تا اینکه تصمیم گرفتم یه پروژه که فرصت زیاد داشت رو بصورت TDD انجام بدم. همیشه فکرمیکردم Unit Testing خیلی راحته و اگر توی تست نوشتن بخوام جاییش گیر کنم قسمت Integration Testing و End to End Testing هست. ولی همون اول کار تا شروع به Unit Test نوشتن کردم، برام کلی سوال جورواجور پیش اومد! مثلا چطوری باید تست‌هارو نامگذاری کرد؟ چطوری میشه متدهایی که نیاز دارند با پارامترهای زیاد تست بشن رو تست کرد؟ حتما باید برای تست نوشتن از mockito استفاده کرد یا نه؟ ادامه …

میخواستم وقتی رسپبری‌پای خریدم، از کارهای جالبی که باهاش میکنم توی کانال و بلاگم بنویسم! ولی خب متاسفانه خیلی فرصت نمیشه سراغش برم، این تعطیلات چند روزه باعث شد تا بعد مدت‌ها سعی کنم کارهایی که میخواستم باهاش انجام بدم رو عملی کنم. مهمترین کارم این بود که بجای وصل کردن لپ‌تاپ به تلویزیون از رسپبری‌پای برای دیدن سریال یا ویدئوهای یوتیوب استفاده کنم. یه روزی درگیر این بودم که یه فیلم FullHD رو روی رسپبری‌پای با زیرنویس فارسی اجرا کنم که آخرشم نشد. (البته میخواستم اینکار رو روی Raspbian انجام بدم، OMXPlayer فیلمو خیلی خوب پخش میکرد ولی با زیرنویس فارسی مشکل داشت)

به این فکرمیکردم که چیکار کنم، یادم افتاد تلویزیون یه بخشی داره که مستقیم به یوتیوب وصل میشه ولی خب اینترنت ایران اون رو باز نمیکنه. درواقع اگر من بتونم یه شبکه‌ای داشته باشم که این قضیه دسترسی رو حل کنه! نه تنها میتونم با همون تلویزیون ویدئوهای یوتیوب رو ببینم، هرجایی که مشکلاتی از قبیل تحریم و دسترسی داشتم (مثل کنسول PS4 یا بیلد کردن پروژه‌های اندروید) با وصل شدن به این شبکه حل میشه!

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

تقریبا یکسال پیش بود که پست کوتاهی در مورد “منابع الهام بخش برای ساخت UI اپ موبایل” نوشتم و تعدادی سایت رو معرفی کردم ولی یه مشکلی وجود داشت، اونم این بود که همه‌ی UIها با زبان انگلیسی درست شده بودند و معمولا وقتی همین UI‌ها رو با زبان فارسی درست می‌کنید، درصد زیادی از زیباییشون از دست میدن. برای حل این مشکل با بچه‌های هارمس تصمیم گرفتیم خودمون زمان بذاریم و از اپ‌های اندرویدی معروف ایرانی اسکرین‌شات تهیه کنیم تا در اختیار همه‌ی برنامه‌نویسان و طراحان فارسی‌زبان بذاریم. خروجی این تصمیم، سایت UI Screenshots شده که در ادامه بیشتر در موردش توضیح دادم. ادامه …

چند وقت پیش یه AMA (فکرکنم معادل فارسیش میشه “از هرچیزی بپرس”) توی reddit بود که تیم توسعه‌دهنده‌ی دگر سوالاتی که ازشون پرسیده شده رو جواب دادن. دیشب وقت کردم بخونمش و نکاتی که بنظرم جالب رو بود رو در ادامه نوشتم. البته اگر میخواید خودتون همه‌ی سوال‌ و جواب‌هارو بخونید، میتونید به لینک زیر برید.

لینک AMA تیم دگر توی reddit ادامه …

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

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

یکی از نکات عجیبی که من توی توییتر میبینم، اینه که خیلیا به این قضیه افتخار میکنند که مثلا یکساعت قبل ارائه اسلایدهارو درست کردن و بعد رفتن ارائه دادن یا فقط یه روز برای آماده‌سازی کل ارائه وقت گذاشتند. بنظر من این قضیه بیشتر از اینکه نشون بده یه نفر خیلی باحال و خفن هس، نشون میده برای اونا که میخوان ارائه‌اش رو ببینن اهمیت قائل نیس. در این رابطه مقاله‌ی “How to Prepare a Talk” که در ادامه لینکشو میذارم یه نکته جالب گفته، اونم اینه که میگه برای آماده‌سازی یه ارائه حداقل باید ۲۰ساعت وقت بذارید! بعد خودش مثال زده که اگر احساس میکنید این زمان خیلی زیاده، اینجوری فکرکنید که ۵۰۰نفر ارائه‌ی ۳۰دقیقه‌ای شمارو میبینند (حضوری،آنلاین یا بعدا ضبط شده)، اگر ۵۰۰*۳۰ رو حساب کنید میشه ۱۵۰۰۰دقیقه نفر-دقیقه که همون ۲۵۰نفر-ساعت هست. حالا واقعا ارزش نداره شما ۲۰ساعت وقت بذارید تا ۲۵۰ساعت بقیه الکی هدر نره؟!

همه‌ جای مقاله‌ “How to Prepare a Talk” که خوبه ولی یه بخش دیگشم برام خیلی جالب بود، همیشه فکرمیکردم من عجیبم که خوشم نمیاد روی کاغذ نکته‌ای بنویسم و همراه خودم برای ارائه ببرم! (چون اینو به عنوان توصیه‌ی خوب برای ارائه زیاد شنیدم)، دلیلشم اینه که سعی میکنم اینقدر تمرین کنم تا با دیدن اسلایدها نکاتی که میخوام بگم یادم بیاد و اگرم نکته‌ای یادم رفته! کلا دیگه یادم بره، نه اینکه توی کاغذ یه چیزی ببینم که نوشته باشم بگم ولی یادم نیاد!!!!! درواقع دوس ندارم دیگه درگیر یه کاغذ بشم و میخوام تمرکزم همون ارائه دادن باشه. حالا وقتی این مقاله رو خوندم، فهمیدم من عجیب نیستم! واقعا این روشی هس که بعضیا استفاده میکنند. تا حالا به کسی اینکاری که خودم میکردمو توصیه نمیکردم، از این به بعد به بقیه پیشنهاد میدم چون ارائه دادن رو راحت‌تر میکنه.

حتما اگر ارائه دادن رو دوست دارید یا میخواید ارائه بدید این مقاله‌ی طولانی رو بخونید. نکاتش خیلی بیشتر از این هست که من بتونم دونه دونه بنویسم و بهتره برید خودشو بخونید.  هرچقدر ازش تعریف کنم، کم هس. تک تک نکته‌هایی که در مورد مراحل آماده‌سازی یه ارائه میگه واقعا تاثیرگذار و کاربردیه. کاشکی به جای اون مطالبی که توی درس “درس شیوه ارائه مطالب علمی وفنی” داخل دانشگاه میگن (البته از همه دانشگاه‌ها خبر ندارم،برای ما که مسخره بود)، از این جور مقاله‌ها معرفی کنن. لینک مقاله “How to Prepare a Talk”:

https://www.deconstructconf.com/blog/how-to-prepare-a-talk

هنوز یه هفته از زلزله‌ی قبلی نگذشته که دوباره یک ساعت پیش یه زلزله‌ی ۴.۲ ریشتری اومد. اومدن زلزله به آدم استرس و نگرانی میده، ولی بدتر از خود زلزله این صحبت‌هایی هست که بعضیا به استناد این کانال پیش‌بینی زلزله (@pishbiniezelzele21) میکنند. هفته‌ی پیش در مورد این کانال زیاد صحبت میشد اما اصلا فکرنمیکردم موضوع دنباله‌داری باشه و مطمئن بودم که حتما توسط پلیس دستگیر میشه و کانال رو مسدود میکنند. حالا نه تنها کانالش مسدود نشده، حتی ۱۰۰هزار نفر به عضو‌هاش اضافه شدن!!!!!

ادعای پیش‌بینی زلزله

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