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

گروه اول- نکاتی که قبل از Open Source کردن یه پروژه باید بهشون توجه کرد.

گروه دوم- نکاتی که وقتی یه پروژه Open Source شد باید بهشون توجه کرد.

 

اگر شمام پروژه‌ای درست کردید که میخواید Open Sourceش کنید یا تصمیم دارید در آینده اینکارو انجام بدید، بنظرم خوندن این مقاله میتونه بهتون کمک کنه. اولین نکته‌ای که باید بهش توجه کنید اینه که گذاشتن یه نمونه کد توی توی گیت‌هاب با داشتن پروژه Open Source متفاوته. یعنی اگر کسی یه نمونه کد رو روی گیت‌هاب بذاره، نمیتونه بگه من یه پروژه Open Source دارم! درواقع اون یه نمونه کد داشته که رایگان در اختیار بقیه برنامه‌نویس‌ها گذاشته. اگر میخواید یه پروژه Open Source داشته باشید بهتر به این سه مورد توجه کنید، اول اینکه پروژه‌‌ای بسازید که مفید باشه، دوم توسعه‌اش رو ادامه بدید و اینجوری نباشه بعد یکی دو هفته بیخیال پروژه بشید، سوم مشارکت بقیه برنامه‌نویس‌هارو توی پروژه‌اش قبول کنید.

 

گروه اول- نکات قبل از Open Source کردن

معرفی پروژه

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

 

انتظار مشارکت زیاد از بقیه برنامه‌نویس‌ها

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

 

مزایای Open Source کردن پروژه

از مزایای Open Source کردن پروژه میشه به موارد زیر اشاره کرد:

۱- باعث آزادی بیشتر میشه. مثلا روی پروژه‌ای کار می‌کنید که صاحبش شرکت هست، Open Source شدنش باعث میشه که در آینده حتی اگر از اون شرکت هم بیرون اومدید، بتونید روش کار کنید.

۲- حس مفید بودن می‌کنید و احساس بهتری پیدا می‌کنید.

۳- با تاثیری که پروژتون رو دنیای برنامه‌نویس‌ها میذاره، برای همیشه یه اثر و ردپا از شما می‌مونه.

۴- راحت‌تر میشه به مشکلاتی که توی پروژه دارید لینک بدید و از بقیه کمک بگیرید. کسی هم که میخواد کمک کنه چون به سورس دسترسی کامل داره، خیلی بهتر کمکتون میکنه.

 

معایب Open Source کردن پروژه

Open Source شدن پروژه در کنار مزایا بالا، معایبی هم داره. مثل:

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

اگر فقط میخواید وظیفه‌ی توسعه دادن کد رو انجام بدید، بهتره به جای اینکه خودتون پروژه Open Source داشته باشید، به یکی از پروژه‌های موجود کمک کنید.

۲- موقع Open Source کردن در نظر داشته باشید که احتمالا این کار باعث میشه کسب درآمدتون سخت‌تر بشه. البته گاهی میشه به جای Open Source کردن کل پروژه‌ای که می‌فروشید و منبع درآمدتون هست، شبیه شرکت Dropbox، کتابخونه‌هایی که برای ساخت پروژه‌ی خودتون درست کردید رو Open Source کنید. اینجوری هنوز میتونید به فروش پروژه‌تون ادامه بدید.
البته توی بعضی موارد مجبورید پروژتون رو Open Source کنید و راه دیگه‌ای ندارید. بطور مثال اگر یه نرم افزار زیرساختی درست کردید(مثل سیستم‌عامل،دیتابیس و …)، انتخاب دیگه‌ای ندارید. هم-بنیانگذار Cloudera گفته که توی ده سال گذشته هیچ نرم افزار زیرساختی با Closed Sourceیی نبوده که بتونه خیلی معروف بشه و عده‌ی زیادی ازش استفاده کنند! توی اینجور پروژها، کاربرها معمولا از استک‌های Open Source استفاده می‌کنند.

۳- برعکس اینکه همه فکرمی‌کنند Open Source کردن باعث میشه هزینه‌ها کم بشه! نه تنها کم نمیشه، تازه زیادم میشه. چون در حالت معمول که کار می‌کنید، کسی اون کد رو نمی‌بینه و فقط کدتون کار کنه! کافیه. اما وقتی کدهارو بقیه می‌بینند مجبورید برای اینکه خجالت زده نشید، کلی وقت براشون بذارید!! همچنین غیر از کد زدن هم وظیفه‌های دیگه‌‌ای مثل داکیومنت نوشتن و … که قبلا بهشون اشاره کردم به کارهاتون اضافه میشند.

 

گروه دوم- نکات بعد از Open Source کردن

جذب مشارکت‌کننده

برای جذب مشارکت کننده میتونید در ازای اینکه کسی توی توسعه پروژه مشارکت کنه، بهش برنامه‌نویسی یاد بدید. شاید اوایل نتونند خیلی بهتون کمک کنند ولی در آینده تعدادی مشارکت کننده دارید که پیوسته روی توسعه پروژه باهاتون همکاری می‌کنند.

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

 

تبلیغ پروژه

معمولا برنامه‌نویس‌ها از اون مدل آدم‌هایی نیستند که خودشون رو تبلیغ کنند ولی توی این مورد باید بکنند! برای شروع میتونید یه پست بلاگ بنویسید یا داخل StackOverflow توی موضوعاتی که به پروژتون ربط داره سوال جواب بدید.

تو بحث‌های برنامه نویسی داخل Hakernews یا Reddit شرکت کنید (اگر بین ایرانی‌ها میخواید تبلیغ کنید، توییتر و تلگرام هست)

با پروژه‌های Open Source دیگه همکاری کنید! شاید پروژه‌تون بتونه بخشی از نیاز اون‌هارو رفع کنه و به عنوان dependency از پروژتون برای خودشون استفاده کنند! این اتفاق پروژه‌تون رو خیلی معروف‌تر میکنه.

 

انتخاب لایسنس

یکی از موضوعاتی که روی پروژه خیلی تاثیر داره اینه که چه لایسنی انتخاب میکنید، مثلا GPL سخت‌گیرانه رو انتخاب می‌کنید یا لایسنس های آسون‌تر مثل MIT


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

لیست تغییرات جدید
حتما لیست تغییرات داشته باشید و حداقل سه قسمت داشته باشه:‍

۱- نسخه‌ی جدید چه ناسازگاری‌هایی با نسخه‌ی قبلی داره

۲- چه ویژگی‌های جدید به سیستم اضافه شده

۳- چه باگ‌هایی در سیستم درست شدند.

حواستون باشه که قرار نیست توی لیست تغییرات یه سری پیام کامیت رو پشت هم بذارید! سعی کنید یه متن واضح و خوب بنویسید

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

راه ارتباطی با کاربرها و مشارکت‌کننده‌ها
توی Gitter کانال درست کنید تا بیشتر با کاربرها در ارتباط باشید، سعی کنید حتما سوال‌هایی که پرسیده میشه رو سریع جواب بدید، اینجوری کاربرا و مشارکت‌کننده‌ها میفهمن که برای اونها و پروژه‌ی خودتون اهمیت قائل هستید.
خیلی بده اگر در نظر نگیریدشون و بهشون اهمیت ندید!

ساخت وبسایت
حتما یه وبسایت برای پروژه درست کنید، یه سایت تک صفحه ای هم خیلی کمک میکنه. میتونید از Github Pages استفاده کنید.

ساخت Readme
فایل readme مناسب برای پروژه درست کنید. میتونید داخلش این موارد رو بنویسید:

۱- پاراگرافی که بصورت خلاصه در مورد پروژتون نوشتید رو داخل بذارید.
۲- توضیح بدید که چطور میشه پروژه رو اجرا کرد.
۳- آدرس وبسایت پروژه رو بذارید
۴- اسم و ایمیل کسایی که توی پروژه همکاری میکنند رو بنویسید

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

ساخت داکیومنت برای کاربران

کار خیلی سختیه ولی به همون اندازه مهمه! بدون راهنمایی کسی نمیتونه از پروژه استفاده!! لازم نیست همون اول کار یه راهنمای کامل بنویسی، یه داکیومنت ساده هم کافیه.
داکیومنت رو جزء ریپوزیتوری نذارید که بعد هر تغییر نیاز به پوش کردن باشه، داکیومنت باید جایی باشه که خیلی سریع و راحت بشه تغییرش داد.

نوشتن داکیومنت برای مشارکت کننده‌ها

‍۱- کدهای پروژه کجاس و چطوری میشه دریافت کردشون.

۲- در مورد فولدربندی پروژه یه توضیح مختصر بدید.

۳- اگر از build system استفاده میکنید، در مورد نحوه‌ی تنظیم کردنش توضیح بدید و بگید dependecyهای پروژه رو چطور باید گرفت.

۴- نحوه‌ی build کردن پروژه و اجرا کردن تست‌هارو توضیح بدید.

۵- شرایط مشارکت کردن توی پروژه رو بنویسید.

 

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

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

منابع

http://blog.smartbear.com/open-source/how-to-turn-your-pile-of-code-into-an-open-source-project

http://www.wikihow.com/Have-a-Successful-Open-Source-Project

https://readwrite.com/2014/07/07/ open-source-software-pros-cons

https://opensource.com/life/15/5/4-steps-creating-thriving-open-source-project

https://www.smashingmagazine.com/2013/01/starting-an-open-source-project

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

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

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

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

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

خروجی این تصمیم، سایت UI Screenshots شده که با آدرس http://uiscreenshots.ir میتونید بهش دسترسی داشته باشید. به دو صورت میشه تصاویر رو فیلتر کنید، روش اول با استفاده برچسب‌هایی که سمت راست صفحه لیست شده‌اند و روش دوم با استفاده از جستجوی نام برنامه‌ای که میخواهید تصاویرشو ببینید.

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

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

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

 

ضعف داکیومنت
یه سری از دولوپرها در مورد اینکه داکیومنت خوب نیست، تذکر داده بودند. چند نفر گیر داده بودن به لغت Thermosiphon که توی مثال استفاده شده :)) توشون یه انگلیسی زبان بود که نوشته بود با اینکه انگلیسی زبانم ولی این لغت رو تا حالا نشنیده بودم!

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

https://google.github.io/dagger/semantics

 

انتشار نسخه ۳

یکی پرسیده بود که نسخه‌ ۳ دگر چه موقع منتشر میشه که گفته بودند تصمیمی برای این قضیه ندارند و فعلا روی همین نسخه‌ی ۲ کار میکنند.

 

دیداری‌سازی (Visualization)

دو نفر در رابطه با Visualization توی دگر پرسیده بودند. مزیت Visualization اینه میشه object graphیی که دگر ساخته رو مثل یه گراف واقعی دید و بررسی کردش.

یکی از اعضای تیم توسعه دهنده خبر از انتشار SPI رو داده بود که هدفش همین کار هست. انگار object graph رو تبدیل میکنه به فایل‌هایی با فرمت dot و میشه این فایل رو از طریق graphviz دید. البته SPI کاملا آزمایشی منتشر شده، مثال هم براش گذاشتند ولی حقیقتش من اصلا نفهمیدم چطوری میشه ازش استفاده کرد. لینک مثال

لینک مثال استفاده از SPI

 

دگر و custom views

یکی پرسیده بود که چطوری میشه از دگر توی custom viewها استفاده کرد که باز یکی از اعضای تیم توسعه دهنده گفته بود که کلا توصیه میکنیم اینکارو نکنید. dependencyهارو باید یه سطح بالاتر از view توی fragment یا Conductor یا هر کنترلر دیگه‌ای که دارید inject کنید.

 

دگر و kotlin

یکی پرسیده بود توی kotlin چطوری از دگر استفاده کنیم بهتره؟ یکی از اعضای تیم توسعه دهنده این لینک رو که منم قبلا توی بلاگ گذاشتمش رو معرفی کرد. توی این issue در مورد best practiceهای استفاده از دگر توی kotlin صحبت میکنند.

https://github.com/google/dagger/issues/900

 

ویدیو آموزشی دگر

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

Understanding Dagger 2’s Generated Code

چندتا کاربر دیگه هم اینا لینک‌هارو توصیه کرده بودن

Dependency Injection Made Simple

 The Future of Dependency Injection with Dagger 2

TwistedEquations – Dagger 2 Android Tutorial

 

ماژول اندروید dagger

یکی پرسیده بود دلیل اینکه dagger.android رو منتشر کردید چیه و بعد چند پیام با یکی از اعضای تیم توسعه‌دهنده صحبت کرده. چون طولانیه، اینجا نمیذارمش و مستقیم برید توی reddit بخونیدش.

لینک به پیام‌ها توی reddit

یه جای دیگه هم یکی گفته بود حتما بجای روش قدیمی getNetComponent().inject(this توی اندروید با از dagger.android و AndroidInjection.inject(this استفاده کنیم؟ یکی از اعضای تیم توسعه‌دهنده گفته بود که میتونید از هرکدوم که میخواید استفاده کنید ولی تیم ما dagger.android رو توصیه میکنه! بعد گفته بود دلیل توصیه‌مون هم مشخصه، چون خودمون درستش کردیم :))

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

حالا برسیم به اصل موضوع که چطوری میشه ارائه‌ی خوبی داشته باشیم. شرایط نسبت به سالهای گذشته تغییر کرده و رویداد‌های زیادی توی کشور برگزار میشن، بطور مثال @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) میکنند. هفته‌ی پیش در مورد این کانال زیاد صحبت میشد اما اصلا فکرنمیکردم موضوع دنباله‌داری باشه و مطمئن بودم که حتما توسط پلیس دستگیر میشه و کانال رو مسدود میکنند. حالا نه تنها کانالش مسدود نشده، حتی ۱۰۰هزار نفر به عضو‌هاش اضافه شدن!!!!!

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

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

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

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

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

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

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

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

ادامه …

در رابطه با فواید خوندن سورس پروژه‌هایی (میتونه خروجیش اپلیکیشن باشه یا کتابخونه) که توسط افراد دیگه نوشته شده مقاله‌های زیادی توی اینترنت وجود داره و لازم به صحبت بیشتر نیست. فقط اگر بخوام تجربه شخصی خودمو بگم، فکرکنم در حدود ۶۰ ۷۰درصد چیزهایی که بلدم رو با خوندن سورس‌ها یاد گرفتم. مهمترین بهونه‌ای که بعضی برنامه‌نویسا میارن تا اینکار پرفایده رو انجام ندن، اینه که میگن هنوز دانششون برای اینکار کم هس. در صورتی که خب بدیهی هست مثلاً اگر منم سورس اپلیکیشن تلگرام رو بررسی میکنم قطعاً کلی از بخش‌هاشو متوجه نمیشم و هیچ‌وقت هم هدفم این نیست ۱۰۰درصد یه پروژه رو متوجه بشم. سورس‌هارو میشه با دو رویکرد زیر بررسی کرد. ادامه …