حدود بهمن یا اسفند سال ۱۳۹۹ بود که من، یک عدد رزبری پای ۴ مدل B (لینک) خریداری کردم که باهاش یه سری ایده رو عملی کنم. از وقتی که این دستگاه رو خریدم، مدت زیادی تقریبا گذشته اما خب چند هفته اخیر، شدیدا با این دستگاه در حال کشتی گرفتن و تست ایده‌های مختلف هستم. یکی از ایده‌های من پروژه‌ای بود که تا حد زیادی به هوش مصنوعی (و بخصوص tensorflow) نیازمند بود. مشکلی که داشتم این بود که در خود مخازن PyPi ای که روی رزبری پای در دسترسه، هیچ ساخت درستی از tensorflow وجود نداره.
اما خب، نمیشه در دنیای تِک ناامید شد؛ به همین خاطر دنبال راهکار و راه حلی گشتم که بتونم تنسرفلو رو روی رزبری پای داشته باشم. یکم سخت‌تر از حالت عادی (که استفاده از pip بود) شد اما ارزشش رو داشت. چون تونستم بدون مشکل مدلی که مدنظر داشتم رو لود و استفاده کنم. همچنین لازمه ذکر کنم که در این مطلب قراره یاد بگیریم چطور خود تنسرفلو رو نصب کنیم و به TFLite کاری نداریم.
رزبری پای چیه؟
رزبری پای (Raspberry Pi) یک کامپیوتر تک‌برد (SBC یا Single Board Computet) محسوب میشه که توسط یک بنیاد غیرانتفاعی به همین اسم در بریتانیا طراحی شده (البته تولیدش مثل عمده محصولات دیگر، در کشور چین انجام میشه). این بردها معمولا یک پردازنده ARM دارند و میشه روی اونها سیستم‌عامل نصب کرد. خیلی‌هاشون هم ورودی/خروجی عام‌منظوره (General Purpose Input/Output) یا همون GPIO دارند که میتونن رابطی بین این کامپیوتر و قطعات الکترونیکی دیگر باشند.
این کامپیوترهای کوچک – که در ابعاد یک کارت اعتباری ساخته شدند – اسباب‌بازی خوبی برای برنامه‌نویسان و مهندسین کامپیوتر به شمار میان. بسیاری از متخصصین و علاقمندان از رزبری پای استفاده می‌کنن تا ایده‌ها و پروژه‌هاشون رو پیاده‌سازی کنن. البته لازم به ذکره که خیلی‌ها هم حتی محصولاتشون رو برپایه رزبری‌پای توسعه دادند (پس اگر دوست داشتید یکی تهیه کنید و باهاش بازی کنید، درنگ نکنید 😁)
تنسرفلو چیه؟
از اونجایی که این مطلب، در مورد نصب Tensorflow روی رزبری پای بود، لازمه که کمی هم در مورد تنسرفلو توضیح داده بشه. تنسرفلو یک کتابخونه نرم‌افزاری آزاد و متن‌بازه که توسط تیم Google Brain توسعه داده میشه. این کتابخونه، به ما اجازه میده که پروژه‌ها و پروسه‌های یادگیری ماشین، هوش مصنوعی، یادگیری عمیق، استنباط آماری و … تا توسعه شبکه‌های عصبی مصنوعی رو انجام بدیم. به خاطر پشتیبانی گوگل از این کتابخونه، به یکی از محبوب‌ترین و پراستفاده‌ترین کتابخونه‌های هوش مصنوعی تبدیل شده (مثلا در پروژه خودران، من از این کتابخونه استفاده کرده بودم).
اما یک مشکل بزرگی با نصب تنسرفلو روی رزبری پای مواجه هستیم. مشکل اینجاست که وقتی دستور روتین pip برای نصب تنسرفلو رو بزنیم، اتفاق خیلی خاصی رخ نمی‌ده، جز این که یک ارور مبنی بر پیدا نشدن این کتابخونه در مخازن PyPi متعلق به پلتفرم ما نشون داده میشه. پس باید چی کار کنیم؟ خب در ادامه قراره که همین داستان رو بررسی کنیم و به نتیجه درستی برسیم.
نصب Tensorflow روی Raspberry Pi
قبل از هرچیزی باید بگم که من این پروسه رو روی Raspberry Pi 4 Model B (با رم ۲ گیگابایت) و سیستم عامل Raspberry Pi OS نسخه Bullseye (بله درست حدس زدید، سیستم‌عامل رزبری پای دبیانه 😁 و صدالبته که میتونید توزیع‌های دیگری هم روش نصب کنید) و ویرایش ۶۴ بیتی طی کردم. بسته به مدل رزبری شما و سیستم‌عاملتون، این پروسه میتونه متفاوت باشه.
نصب نرم‌افزارهای پایه
ما برای این که بتونیم تنسرفلو رو نصب کنیم، نیاز به نصب تعداد زیادی نرم‌افزار روی خود سیستم‌عامل داریم. به نظر بهتره که ابتدا، لیست بسته‌های مخازن رو بروزرسانی کنیم:
sudo apt update
و صدالبته بهتره که خود سیستم‌عامل هم بروزرسانی‌های آخرش رو دریافت و نصب کنه:
sudo apt full-upgrade
پس از این که این مراحل انجام شد، تعداد زیادی نرم‌افزار رو به این شکل نصب می‌کنیم:
عمده این نرم‌افزارها رو بر اساس پیام‌های خطایی که دریافت می‌کردم پیدا کردم، چرا که وقتی شما روی سیستم دسکتاپ یا لپتاپ خودتون تنسرفلو نصب می‌کنید، بسیاری از اینها (متناسب با معماری پردازنده) پیش‌تر نصب شدند اما سیستم‌عامل‌هایی که روی رزبری نصب می‌کنیم چنین حالتی ندارند. بهرحال، همه نرم‌افزارهای پایه‌ای که نیازه از مخزن دبیان نصب بشه، در این دستور موجوده (طبیعتا اگر نیاز به بسته دیگری باشه بعدا این مطلب ویرایش میشه)
نصب و بروزرسانی بسته های پایتونی
خب ما تعدادی پیش‌نیاز پایتونی هم داریم (که اینها رو اکثرا حتی در وبسایت تنسرفلو هم میشه پیدا کرد) که با دستورات زیر نصبشون می‌کنیم:
توجه کنید که اگر این دستور کار نکرد هم جای نگرانی نیست، میتونید این لینک رو باز کنید و فایل رو خودتون دانلود کنید.
سپس کافیه که با اجرای این دستور:
pip3 install <TENSORFLOW WHL FILE>.whl
نصب رو انجام بدید.
ضمنا، از اونجایی که ممکنه بعدتر نسخه‌ها تغییر کنن، بهتره که این صفحه رو هم هر چند وقت یه بار چک کنید تا اگر نیاز بود نسخه تنسرفلو رو تغییر بدید، فایل مربوطه رو دانلود کنید.
جمع‌بندی
مدتهای زیادی میشه که دوست دارم در مورد پروژه‌هایی که در حوزه «اینترنت چیزها» یا همون IoT انجام میدم هم بنویسم. اما متاسفانه پروژه‌های سخت‌افزاری، وقت زیادی از آدم می‌گیرن و وقتی وقت آزاد زیادی نداشته باشید، معمولا به پروژه‌های سخت‌افزاریتون هم آنچنان نمی‌تونید رسیدگی کنید. به همین خاطر مدتی میشه که در تلاشم تا پروژه‌های شخصی و صدالبته کاریم در حوزه بینایی ماشین رو با IoT ترکیب کنم و به این شکل این حوزه رو هم وارد کارهای روتین و اصلیم کنم که وقت هم همیشه براشون باشه 😁
تست چند پروژه بینایی ماشین روی Raspberry Pi شروعی برای این دوران از زندگی منه. راستی، اگر دوست دارید نقشه راه بینایی ماشین رو داشته باشید میتونید بیایید اینجا، اگر دنبال ایده برای پروژه‌ها هستید هم اینجا رو بخونید. حتی میتونید به ما در جامعه بینایی ماشین هم ملحق بشید و اشتراک تجربه و دانش کنید.
چندی پیش، در مورد پیش‌نیازهای یادگیری بینایی ماشین در همین وبلاگ نوشته بودم (لینک) و بعد از اون هم در مطلبی در ویرگول، در مورد این که چرا موجودیتی به اسم «جامعه بینایی ماشین» رو راه انداختم (لینک) صحبت کردم. پس از انجام چندین پروژه و تولید چندین محتوا پیرامون این موضوع، امروز در این پست قراره که ایده هایی که شما میتونید در پروژه های بینایی ماشین و پردازش تصویر خودتون به کار بگیرید رو بررسی کنیم.
توجه داشته باشید که در این پست، فرض رو بر این گذاشتیم که شما با هوش مصنوعی، پایتون، بینایی ماشین و … آشنایی لازم و کافی رو دارید و حالا قصد دارید یک پروژه جدی باهاش انجام بدید اما نمی‌دونید باید چی کار کنید. اگر آشنایی ندارید هم مشکلی نیست، میتونید این مطلب رو صرفا برای ایجاد علاقه و یا رفع کنجکاوی بخونید 😁
ایده های مرتبط با تشخیص چهره
تشخیص چهره، همیشه یکی از پرطرفدارترین شاخه‌های پردازش تصویر و بینایی ماشین بوده است. چرا که با استفاده از تشخیص چهره، می‌توانیم عملیات جالبی انجام دهیم و پروسه‌های زیادی از یک کار بزرگتر را، خودکار کنیم. همچنین می‌توانیم امنیت خانه و محل کار و … را نیز با استفاده از تشخیص چهره تامین کنیم.
در لیست زیر، تعدادی از پروژه‌های مرتبط با تشخیص چهره رو برای شما فهرست کرده‌ام:
حضور و غیاب مبتنی بر چهره
دوربین امنیتی (به این شکل که وقتی شخص ناشناسی وارد حریم دوربین شد از طریق ایمیل یا SMS و … به شما اطلاع بده)
قفل هوشمند ( به شکلی که اگر شما رو دید در رو باز کنه و در غیر این صورت، یک سیستم مانند دزدگیر یا سیستم امنیت خونه رو راه‌اندازی کنه)
تشخیص حالت و احساسات چهره
تشخیص خواب‌آلودگی (مثلا در یک کلاس این پروژه میتونه کاربردی باشه).
همه ایده‌های بالا، به سادگی قابل انجام هستند. فقط کافیه که کار با کتابخانه‌ها و تئوری پردازش تصویر رو بلد باشید. شاید دو سه روزه بتونید یکی از این پروژه‌ها رو به ثمر برسونید 😁
ایده های مرتبط با تشخیص کرکتر
تشخیص نوری نویسه یا Optical Character Recognition که به اختصار به اون OCR هم گفته میشه، یکی از شاخه‌های پرطرفدار دیگر در حوزه بینایی ماشین میتونه به حساب بیاد. پروژه‌هایی که در این حوزه انجام میشن به شدت کاربردی هستند و طبیعیه که در حوزه‌های مختلفی کاربرد خواهند داشت. در اینجا تعدادی از ایده‌هایی که میتونید روش کار کنید رو اینجا فهرست کردم:
تشخیص و استخراج شماره پلاک (که پیش‌تر در موردش نوشتم – لینک)
تشخیص و حل مسائل ریاضی/فیزیک (که این هم پیش‌تر در مورد نوشتم – لینک)
تشخیص دست‌خط فارسی
تشخیص خط نستعلیق (و در کل خوشنویسی) فارسی
تشخیص نسخه پزشکی (نکته جالب اینه که در نسخ پزشکی، بسیاری از خط‌خطی‌هایی که می‌بینید در واقع روش مصرف و دوزاژ دارو هستند، که طبق کدگذاری خاصی نوشته میشن).
البته باید این نکته رو هم عرض کنم خدمتتون که دنیای OCR خیلی گسترده‌ست. تقریبا هرجایی که شما با نوشتن سر و کار داشته باشید، میتونید از OCR هم اونجا استفاده کنید. خیلی چیزا اینجا به خلاقیت و نیازهای خودتون برمی‌گرده. اگر ایده دیگری داشتید، میتونید در بخش نظرات همین مطلب با من به اشتراک بذارید.
ایده های مرتبط با پزشکی
هوش مصنوعی در علم پزشکی، جایگاه خاصی در سال‌های اخیر داشته. چرا که همه دانشمندان کامپیوتر و همچنین پزشکی، دریافتند که با استفاده از راه‌حل‌های هوشمند، می‌تونند به حد قابل توجهی، خطاهای پزشکی رو کاهش بدند. همچنین تحقیقات دارو و واکسن هم به شدت سریع‌تر میتونن انجام بدند. برای مثال، همین دنیاگیری ویروس کرونا که در سال ۲۰۱۹ آغاز شد و کماکان ادامه داره رو بررسی کنیم، بارها از این که از هوش مصنوعی برای پیدا کردن ترکیبات دارویی موثر بر ویروس استفاده شده، صحبت کردند. همچنین در پروسه ساخت واکسن هم بسیاری از مراحل رو به ماشین سپردند و به هوش ماشینی اعتماد کردند. شاید یکی از دلایلی که واکسن این بیماری انقدر سریع ساخته شد، استفاده از همین راهکارهای هوشمند در تولید بوده.
بینایی ماشین هم استثناء نیست و طبیعتا میتونه خیلی به کمک افراد بیاد. در این بخش، تعداد زیادی از ایده‌هایی که میتونه به پزشک‌ها در شناخت بهتر مشکلات بیمارهاشون کمک کنه رو فهرست کردم و خب بد نیست اگر شما هم سراغش برید و سعی کنید یکیش رو پیاده کنید (این بخش میتونه برای دانشجویان مهندسی پزشکی و پزشکی؛ بسیار مفید باشه)
تشخیص نوع تومور مغزی (تصویر این بخش، پروژه‌ای که خودم انجام دادم)
تشخیص رتینوپاتی دیابتی در اشخاص مبتلا به دیابت
تشخیص MS و مراحل مختلف اون بر اساس MRI
تشخیص سلول‌های سرطانی
تشخیص میزان درگیری ریه در بیماری‌های تنفسی (مانند COVID-19)
تشخیص ناهنجاری‌های پوستی
تشخیص آسیب‌های استخوان
تشخیص آسیب‌دیدگی‌ها و پوسیدگی‌های دندان
طبیعتا اینها، همه کارهایی که میتونیم در حوزه پزشکی با کمک بینایی ماشین و پردازش تصویر انجام بدیم نیستن و این دامنه میتونه به شدت گسترده‌تر باشه. طبیعیه که گستردگی این دامنه به خلاقیت خودتون و نیازهاتون برمی‌گرده. همچنین طبیعتا اگر شما دانشجوی مهندسی پزشکی یا رشته پزشکی و رشته‌های مرتبط باشید، احتمالا ایده‌های بهتری خواهید داشت.
سایر حوزه‌ها
چندین و چند حوزه دیگر هست که خب مثل باقی حوزه‌های پوشش داده شده در این مطلب، نمیشه ایده‌های پروژه‌های بینایی ماشین و پردازش تصویرشون رو فهرست کرد. به همین خاطر، توضیح اجمالی راجع به هر کدوم میدم تا شما ببینید که کدوم حوزه رو بیشتر دوست خواهید داشت و در کدوم حوزه ممکنه بتونید ایده‌پردازی بهتری داشته باشید.
تشخیص حرکت یا Action Detection
این حوزه به طور خاص، میتونه برای کارهایی مثل تشخیص و ترجمه همزمان زبان اشاره (لینک)، تشخیص حرکات ورزشی و یا تشخیص «نیت» افراد بشه. برای مثال، میتونیم سیستمی بسازیم که حرکات بعدی فرد در یک نبرد تن به تن (مثل مسابقه بوکس) رو پیش‌بینی کنه و به مربی‌ها و نوآموزهای اون رشته اطلاع بده.
خودروهای خودران
خودروهای خودران یا Self-Driving که پیش‌تر هم ازشون در همین وبلاگ صحبت کرده بودم (لینک) میتونن با استفاده از بینایی ماشین و پردازش تصویر، تابلوهای راهنمایی، رفتار سایر رانندگان، موانع در مسیر و … رو تشخیص بدند. این حوزه البته پیچیدگی زیادی داره اما کار کردن روی بخش‌های مختلفش میتونه برای یادگیری جوانب مختلف ماجرا جذاب و جالب و مفید باشه.
مصرف انرژی
حوزه انرژی هم حوزه جالبی میتونه برای پروژه‌های بینایی ماشین باشه. برای مثال OCR ای که بتونه دیتای کنتور گاز/برق رو به متن تبدیل کنه و اون رو با یک مرکز محاسبه قیمت، چک کنه و قیمت رو به ما اعلام کنه. همچنین میشه عکس‌های حرارتی از خانه‌ها و … تهیه کرد و با استفاده از بینایی ماشین دقیقا بررسی کرد که کجاها انرژی بیشتری داره از دست میره و … .
این پروژه‌ها به خودی خود شاید جالب به نظر نرسن اما ترکیبشون با IoT و هوشمندسازی در سطوح دیگر، طبیعتا میتونه جذاب و حتی پول‌ساز هم باشه.
کشاورزی
این هم گفتن نداره، شما کافیه که یک سری عکس هوایی از زمین‌های کشاورزی داشته باشید. احتمالا خیلی راحت بتونید سیستمی توسعه بدید که آفات رو شناسایی کنه. همینطور میتونید نوع خاک و … هم از روی این عکس‌ها طبقه‌بندی کنید و پیشنهاد بدید که چه محصولی در این زمین کشت بشه بهتره. در حوزه مصرف انرژی هم میتونید یکی از پروژه‌ها رو بردارید بیارید اینجا و ازش بهره‌برداری کنید. چی از این بهتر؟
ضمن این که امنیت زمین کشاورزی و گلخانه، بررسی نور و رنگ و … هم میتونن اینجا کاربردی باشند.
جمع‌بندی مطلب
در این مطلب، ایده‌هایی که میتونید بعنوان یک پروژه تفریحی یا جدی پیاده‌سازی کنید رو بررسی کردیم. همچنین این ایده‌ها، به جز این که میتونن رزومه خوبی برای شما بسازند طبیعتا میتونن پایه یک کسب و کار و یا یک استارتاپ باشند که شانس خوبی برای به پول رسیدن داره. به همین خاطر هم ممنون میشم اگر هر کدوم از این ایده‌ها رو پیاده‌سازی کردید در بخش کامنت همین مطلب در موردش بنویسید و به من اطلاع بدید تا ببینم چه کردید.
همچنین لازم به ذکره که اگر دوست دارید مطالب فنی/علمی دیگری از من بخونید، میتونید به ویرگول من هم مراجعه کنید. در پایان هم بابت وقتی که گذاشتید، ازتون تشکر می‌کنم و امیدوارم در آینده باز هم بتونم در این وبلاگ، مطلب بنویسم.
دقیقا دو هفته پیش، در نسخه انگلیسی وبلاگ در مورد YOLOv5 نوشتم (لینک) و توضیح دادم که چرا این مدل هوش مصنوعی برای تشخیص اشیاء رو دوست دارم (و حتی چرا شما باید دوستش داشته باشید) و خب طبیعتا دوست داشتم یک پروژه خیلی خیلی ساده و در عین حال باحال هم با این مدل انجام بدم.
ایده‌های زیادی در سر داشتم. برای مثال ایده بازی Red Light – Green Light که در سریال اسکوییدگیم همه دیدیم. اما این ایده علیرغم خوب بودنش، آنچنان کاربردی نبود. پس تصمیم من برآن شد که یک نرم‌افزار دیگر توسعه بدم. نرم‌افزاری که هم چالش داشته باشه، هم در نهایت یک کاربرد درست ازش بشه درآورد.
نمی‌دونم شما یادتونه یا نه، اما نرم‌افزار سیمبولب، دروانی خیلی خاص و معروف شد. به همین خاطر، تصمیم من هم این شد که سیمبولب رو دوباره بسازم و بعد از این که نتایج مورد نظرم رو گرفتم در موردش وبلاگ بنویسم. پس این شما و این ماجرایی که من داشتم تا این نرم‌افزار رو بسازم.
گام اول: طرح مساله
در هر پروژه‌ای، اولین گام اینه که مطرح کنیم چه مشکلی رو باید حل کنیم. یا به قول دنیل کوهن Look for the pain. خب دردی که ما اینجا به دنبال حل کردنش بودیم، چی بود؟ این که بسیاری از دانش‌آموزا و دانشجوها سر ریاضی عمومی یا Calculus مشکل دارند. این مشکل ریشه‌ش کجاست؟ برای من شخصا مهم نیست که این ریشه رو بررسی کنم (البته به معنای این نیست که نظری در موردش ندارم، اما از حوصله این مطلب خارجه).
حالا درد این که بسیاری از دانشجوها و دانش‌آموزها مشکل دارند، چطور میشه براشون یک مسکن خوب تجویز کرد؟ بعنوان یک مهندس هوش مصنوعی، یا بهتر بگم مهندس بینایی ماشین در ذهنم این ایده چرخید و اون این بود که:
یک نرم‌افزار هوش مصنوعی وجود داشته باشه که از روی عکس مساله، پاسخ نهایی یا راه‌حل رو به افراد بده.
و این پروژه، در نظر پروژه بسیار بسیار بزرگی بود اما در نهایت، پروژه ساده‌ای شد. در ادامه، در راهی که طی شد توضیح خواهم داد.
گام دوم: انتخاب ابزار
گام دوم برای من، انتخاب ابزار بود. اول از همه می‌خواستم برم سراغ OCR های آماده برای تشخیص مسائل پارامتری مثل x و y و … . اما بعد دیدم که اینجا علاوه بر حروف و اعداد، نشانه‌ها هم هستند. ضمن این که به شکلی باید توان و … هم تشخیص داد. پس کمی پروژه رو نگه داشتم تا به ابزارها فکر کنم.
بعد از مدتی تحقیق و تفحص، به دارک‌نت رسیدم که برای ترین کردن YOLOv3 و YOLOv4 استفاده میشه و خب دارک‌نت مشکلات زیادی هم با خودش به همراه داره. برای مثال کاملا در سی‌پلاس‌پلاس نوشته شده و روی سیستم‌های مختلف باید از نو کامپایل بشه. با CPU درست کار نمی‌کنه. کامپایل کردنش روی مک یا ویندوز دردسره و انتقال دادنش به Google Colab هم میتونه تا حد زیادی مشکل‌ساز بشه.
بعد از اون الگوریتم YOLOv5 رو کشف کردم. تقریبا همه مراحل کاملا پایتونی پیش می‌رفت و این عالی بود. کم کم دیدم که میشه بعد از ترین کردن قضیه، از pytorch هم استفاده کرد و اشیاء رو تشخیص داد و از اون بهتر این بود که در تشخیص اشیاء، می‌شد خروجی pandas هم گرفت که مختصات شیء مورد نظر به همراه لیبلش در اون data frame خاص موجود بودند. پس به این شکل تشخیص این که ما با چه چیزی روبرو هستیم هم ساده‌تر از گذشته می‌شد.
وقتی این ابزار رو با چند چیز مختلف تست کردم، نوبت این رسید که در این پروژه حتما ازش استفاده کنم. اما این تمام ماجرا نیست. دقیقا وقتی که سمت OCR ماجرا هندل می‌شد، یک بحث خیلی مهم می‌موند. بحث این که چطوری باید مساله حل بشه؟ برای حل مساله هم از Wolfram Alpha گفتم کمک می‌گیرم.
خب حالا نوبتی هم باشه، نوبت اینه که داده‌های مورد نیاز رو جمع کنیم. قبل‌تر در مورد راه‌هایی که شما میتونید برای جمع‌آوری داده استفاده کنید، صحبت کردم و میتونید از اینجا بخونیدش.
نمونه داده‌های استفاده شده در این پروژه
گام سوم: جمع‌آوری داده
برای جمع‌آوری داده‌ها، نیازمند این بودم که روی چند سطح مختلف (وایت‌برد، کاغذ A4 و همچنین کاغذ خط‌دار) و با چند دست‌خط مختلف، مسائل ریاضی رو بنویسم. بعد از نوشتن مسائل ریاضی، از دوستانم خواهش کردم که روی صفحات مختلف و همچنین وایت‌برد، مسائل ریاضی رو بنویسند.
بعد از این که مسائل ریاضی رو روی این سطوح و با دست‌خط‌های مختلف داشتم، نوبت عکاسی ازشون بود. از هر بار نوشتن، چندین عکس از چند زاویه گرفتم. چرا که زوایای مختلف باعث میشن توزیع نور هم در تصاویر یکسان نباشه و این خودش یک مرحله data augmentation رو برای من کاهش می‌داد.
حالا یه حجم زیادی داده دارم، باید بعدش چی کار کنم؟ پاسخ ساده‌ست. الان زمانیه که ما وارد مرحله پیش‌پردازش داده میشیم.
گام چهارم: پیش‌پردازش داده
بعد از این که ما داده‌های مورد نیاز خودمون رو جمع کردیم، نیازمند اینیم که داده رو پیش‌پردازش کنیم. به طور کلی، پیش‌پردازش داده به پروسه‌ای گفته میشه که در اون قراره داده ها تمیز بشن، تغییر کنند (یا به قولی data augmentation رخ بده)، برچسب زده بشن و داده‌های غیرلازم (یا همون نویز) دور ریخته بشه.
اولین مرحله برای من اینجا، تکه تکه کردن عکس بود. شاید فکر کنید که برای تکه تکه کردن عکس، از ابزار خاصی استفاده کردم یا کدی زدم. باید بگم که خیر، ابزارم دقیقا ادوبی فتوشاپ و ابزار Slice بود. بعدش با قابلیت save for web آمدم و عکس‌های قطعه‌قطعه شده رو ذخیره کردم. پس از ذخیره نهایی عکس‌ها، نیاز بود که عکس‌ها برچسب زده بشن.
برچسب‌ها، در مرحله آموزش مدل، به ما کمک می‌کنند که اشیاء رو در تصاویر پیدا کنیم. این برچسب‌ها در مراحل بعدتر به کمک ما میان تا بتونیم مسائل یافت شده رو به ولفرام‌آلفا بدیم تا برامون حلش کنه. پس لازم بود که این اتفاقات بیفته.
گام پنجم: آموزش مدل YOLOv5
و اما گام یکی مونده به آخر دقیقا این بود که مدل آموزش داده بشه. آموزش این مدل با pytorch به شدت سرراست و راحته و کلش اجرا کردن یک دستور در ترمیناله. باز با این حال، مشکلات عدیده‌ای داشتم. برای مثال روی لپتاپ شخصی چون GPU مناسب نداشتم، آموزش به شدت طولانی می‌شد. آموزش رو به Google Colab منتقل کردم و چون پلن رایگان داشتم، اونجا هم یک سری داستان جدیدتر پیش آمد. اما بهرحال هرطور که شد، مدل آموزش داده شد و نتایج خوبی هم ازش گرفتم.
در مورد آموزش مدل و نحوه کار اون به زودی محتوای آموزشی جدیدی تولید خواهد شد که به تفصیل در اون توضیح میدم چطور میتونید YOLOv5 رو خودتون آموزش بدید و باهاش کار کنید. در حال حاضر، توضیح مراحل آموزش تا حد زیادی از حوصله این پست وبلاگ خارجه.
و گام نهایی: آزمایش مدل و نوشتن رابط ولفرام آلفا
پس از این که مدل آموزش داده شد، نیاز بود چندین خط کد پایتون نوشته شه برای چند منظور. اول این که وزن‌هایی که لازم بود از مدل آموزش‌داده‌شده، لود کنه. دوم این که یک عکس رو از ورودی بگیره و مراحل inference رو روش انجام بده و در نهایت، اگر کاربرخواست اون رو بفرسته به ولفرام آلفا و مرورگر رو براش باز کنه.
برای این مرحله، برخلاف باقی مراحل وقت زیادی نذاشتم ولی با این حال کدش (بدون وزن‌ها) در گیت‌هاب شخصی من موجوده و میتونید نگاهی بندازید. البته که به زودی گیت‌هاب بروزرسانی میشه و شما قادر خواهید بود که وزن‌ها رو هم دانلود کنید. اما فعلا وزن‌ها در دسترس نیستند.
در نهایت هم برای این که عملکرد قضیه رو ببینید، این ویدئو کوتاه رو میتونید تماشا کنید که هم inference رو تست می‌کنیم هم حل مساله با ولفرام رو:
جمع‌بندی و مشکلات این نرم‌افزار
این پروژه به عنوان یک پروژه تفریحی، واقعا تفریح خوب و سالمی بود و کلی یادگیری برای من داشت. یادگیری دقیق‌تر و عمیق‌تر YOLOv5، یادگیری دقیق‌تر و عمیق‌تر PyTorch و از همه مهم‌تر درگیر شدن با چند مساله و به قولی، دردهای دنیای واقعی. از نتیجه کاملا راضی بودم و هستم، اما فکر نکنم در آینده این پروژه خیلی برام راضی‌کننده باشه.
احتمالا بعد از مدتی به این پروژه برگردم و بزرگترین مشکلش – یعنی شباهت زیاد ورودی‌ها به هم – رو طور دیگری هندل کنم. برای این که ببینیم یه چیزی در پوزیشن توان یه چیز دیگه قرار گرفته یه چاره‌ای بیاندیشم و … . خلاصه که راه برای بهبودش زیاده و این بهبود‌ها رو شخصا پیگیر هستم که در این پروژه اعمال کنم. شاید هم لازم باشه داده ورودی رو افزایش داد یا حتی مدل مورد استفاده رو عوض کرد.
در نهایت، از شما بابت وقتی که برای خوندن این مطلب گذاشتید، ممنونم. امیدوارم که این مطلب مفید واقع شده باشه و به دردتون خورده باشه. ضمن این که اگر به این تیپ مسائل و مطالب علاقمند هستید، میتونید من رو در ویرگول هم دنبال کنید و اونجا هم مطالبم رو بخونید. اگرچه در ویرگول عمده مطالبم مرتبط با بیزنس، موفقیت و ایناست.
در نهایت از شما خواهش می‌کنم که اگر این مطلب براتون مفید بود، یک قهوه به انتخاب خودتون مهمانم کنید تا موقع نوشیدن قهوه به یادتون باشم و از این دست مطالب، بیشتر تولید کنم.
در دو پست قبلی (+، +) در مورد پروژه جبیر با شما صحبت کردم و توضیح دادم که ایده‌ش از کجا اومد و چی شد و چه کردیم. قسمت دوم یکم پرش قلم من زیاد بود چون موضوعات زیادی رو شامل می‌شد اما خب نیاز بود که گفته بشه. حالا رسیدیم به قسمت آخر. در این قسمت، میخوام از این بگم که در جشنواره خوارزمی چه گذشت و چرا جشنواره خوارزمی شروعی بود بر پایان این پروژه.
بذارید قبل از هرچیزی، یک مرور کلی داشته باشیم بر دو قسمت قبلی. در قسمت اول، توضیح دادم که من شیفته اپل شده بودم و می‌خواستم مثل استیو جابز، یک شخصیت مهم در دنیای تکنولوژی باشم و همون قدر شناخته بشم و همونقدر هم ثروتمند (بالاخره آرزو بر نوجوانان عیب نیست، هست؟) و تصمیمم این شد که یک سیستم عامل بسازم و بعد از کلی تحقیق و توسعه؛ نتیجه این شد که یک سیستم عامل مبتنی بر گنو/لینوکس و توزیع اوبونتو بسازم. اسم این پروژه هم گذاشتیم جبیر.
در قسمت دوم، از فراز و نشیب‌های فنی این قضیه گفتم. از این گفتم که چی شد که اینطوری شد و چی شد که ساخته شد. بذارید ساده‌تر و مفصل‌تر بگم، اول گفتم که فاز تحقیقم چی بود و چه کردم و چه چیزایی خوندم. بعد گفتم که چرا تصمیم گرفتم بیام سراغ سیستم‌عامل‌های متن‌باز موجود مثل لینوکس یا BSD و در نهایت گفتم چرا لینوکس رو انتخاب کردم. بعدش از عادت Distro Hopping گفتم (این عادت یعنی که شما بیایید و توزیع‌های مختلفی تست کنید و همیشه روی یک توزیع ثابت نمونید) بعدش هم گفتم چی شد که مینت و اوبونتو رو به عنوان مبنا در نظر گرفتم و چطور نسخه‌های اولیه جبیر ساخته شد.
بعد از اون، از انتشار جبیر و اشتباهاتی که در ساخت این پروژه شد نوشتم. بعد از این موضوع، وارد بحث نسخه ۴ که نسخه جنجالی جبیر بود شدیم (نسخه‌ای که به اینترنت متصل نمی‌شد، به همراه نظر جادی و تبعاتش) و بعد از اون چه شد که به سراغ BSD رفتیم و همین موضوع هم مزید بر علت شد که جبیر روز به روز به پایان خودش، نزدیک‌تر بشه.
جشنواره خوارزمی
جشنواره خوارزمی، یک جشنواره‌ست که در سطوح مختلف (چه مقطع تحصیلی و چه تقسیمات جغرافیایی) برگزار میشه و یکی از اهدافش، اینه که به مخترعین و مبدعین و محققین جوان کمک کنه تا نتایج کارهاشون دیده بشه. مقام آوردن در این جشنواره، خودش یک سری امتیاز خاص به همراه داره که این امتیازات عبارتند از دانشگاه بدون کنکور رفتن (طبیعتا در رشته‌ای که پروژه/اختراع ارائه کنید) و معافیت سربازی و اینها. البته اینها مال اون زمان بود و الان نمی‌دونم چطور شده ولی فکر نمی‌کنم تغییری کرده باشه.
احتمالا اگر الان این رو خوندید و دبیرستانی هستید، براتون خیلی دغدغه شده که حتما در این جشنواره‌ها شرکت کنید، ولی خواهش می‌کنم که قبلش حتما مطلبی که اول این پست لینک شده رو یه نگاه بندازید. قدیمیه ولی ارزشش رو داره. خلاصه بگذریم؛ چیزی که اینجا مهمه اینه که شما بدونید اگر طرحتون به زعم داوران جشنواره واقعا خوب بیاد، امتیازاتی دریافت می‌کنید که میتونه شما رو به اهداف زندگیتون نزدیک کنه.
حقیقتا من از وقتی بچه‌تر بودم، بچه‌هایی که به این جشنواره راه پیدا می‌کردند رو از تلویزیون و روزنامه و … دنبال می‌کردم، دلم می‌خواست روزی مثل اونها باشم. مادامی که در تهران در مقطع راهنمایی تحصیل می‌کردم خبری از این جشنواره برای دانش‌آموزان راهنمایی نبود (سالی که ما شرکت کردیم ولی بود) و همین امر، باعث شده بود که من با این تیپ جشنواره‌ها غریبه باشم. اما در دبیرستان اوضاع فرق کرد. ما این پروژه رو شروع کرده بودیم. بخصوص سال دوم دبیرستان که بودم، رضا باقرزاده عزیز هم به من پیوست و با هم پروژه جبیر رو پیش می‌بردیم.
یک روز، ما از مدیر مدرسه‌مون خواستیم که سالن اجتماعات مدرسه رو در اختیارمون بذاره و از بچه‌هایی که اون ساعت خاص، بیکارن دعوت کنه که بیان و پروژه ما رو ببینن. این هم خودش یکی از حرکات «استیو جابز»گونه بود 🙂 خلاصه این اتفاق افتاد و از قضا، مدیر مدرسه هم خودش اومد در اون جلسه دورهمی حضور پیدا کرد. این قضیه برای ما خیلی خوب بود چرا که حسابی در چشم مدیر مدرسه، درخشیده بودیم.
اما این تمام ماجرا نبود …
روز بعد اون کنفرانس، مدیر مدرسه از من و رضا درخواست کرد که جزییات پروژه رو براش بنویسیم. من هم یک صفحه A4 نوشتم تحویلش دادم. یک هفته بعد، ما رو از سر کلاس (که اگر اشتباه نکنم دینی بود) خواستند به دفتر. ما اول کمی ترسیده بودیم (بهرحال سیستم آموزشی ما ایجاب می‌کنه که از دفتر بترسیم 😂) و وقتی رفتیم، دیدیم یک آقای میانسالی هم اونجا هستند. مدیر مدرسه به ما گفت که ایشون از مسولین آموزش و پرورش استان هرمزگانن و پروژه ما در مرحله استانی خوارزمی پذیرفته شده.
ایشون گفت که روز بعدش، بریم پیشش. پرسیدیم بعد مدرسه؟ گفت نه، از مدیرتون اجازه بگیرید و دو زنگی رو ما در خدمتتون هستیم. ما هم از این بابت خوشحال شدیم. می‌دونید چرا؟ چون بالاخره دو زنگ پیچوندن هم خودش صفای خودش رو داشت. حالا از این حال و هوا بیاییم بیرون. ما فرداش رفتیم پیش ایشون. ایشون ما رو برد پیش مسولین خوارزمی و کلی تحویلمون گرفتند. این تحویل‌گیری‌ها البته دلیل داشت! دو سه سالی بود که از استان هرمزگان در رشته کامپیوتر هیچ پروژه‌ای معرفی نشده بود و اینها هم از این موضوع حسابی خوشحال بودند.
خلاصه که این دوستان، به ما گفتند یک A4 کافی نیست و در قالب یک پرپوزال باید در مورد پروژه بنویسیم. من و رضا هم گفتیم پس ما می‌ریم روی این کار می‌کنیم و می‌آییم پیش شما. اون خانمی که در آموزش پرورش به ما گفت که بعدا بریم پیشش، گفت که چهارشنبه ها عصر هم حضور داره در همون دفتر و نیازی نیست کلاس رو بخاطر قرار با ایشون بپیچونیم. خلاصه کلام که ما رفتیم و یک فایل ۲۰-۳۰ صفحه‌ای با عنوان «سیستم‌عامل جبیر» نوشتیم و این رو پرینت کردیم و در طلق و شیرازه قرار دادیم و چهارشنبه بردیم پیش ایشون.
بعد از کمی بررسی، غلط‌های این پرپوزال رو به ما گفت و ما اون رو اصلاح کردیم. بعدش به ما گفتند که تا تیرماه حدودا صبر کنیم (و این ماجرا حدودای فروردین اتفاق افتاد اگر درست یادم باشه). ما هم به درس و مشقمون رسیدیم و امتحان دادیم. اما خب اینجا یک سری اتفاق خاص هم افتاد.اتفاقاتی که به نوبه خودشون جذاب و جالب بودند.
جشنواره خوارزمی استانی
جشنواره استانی، برخلاف کشوری، اینطوری نیست که شما بری از پروژه دفاع کنی. بر اساس همون توضیحاتی که از پروژه‌ها ارائه شده، داوری می‌کنند و اونایی که حس میشه شانس خوبی برای مقام کشوری آوردن دارند انتخاب میشن. بعد از این، این مورد به صاحبان ایده و پروژه، ابلاغ میشه.
در همین حین، ما که سخت مشغول کار روی جبیر بودیم و حتی یادمه که دونفری با رضا می‌رفتیم پیش خدمات کامپیوتری‌ها که مجابشون کنیم که یکی دو تا سیستم بدن دست ما که روش جبیر نصب کنیم (شاید باورتون نشه ولی یکی از پلن‌های من، برای هر توزیعی که درش نقشی داشتم تولید کامپیوترهای رومیزی با همون سیستم‌عامل هم بوده) و معمولا اونها هم یه چراغ سبز الکی نشون میدادن، یک باره به تلفن رضا زنگ زدند. رضا گفت «آقای …؟» و بعد گوشی رو روی اسپیکر گذاشت و به ما اعلام شد که در استانی، رتبه اول شدیم (لینک خبر).
در مورد تاریخ خبر باید به شما بگم که این اخبار، بعد از برگزاری جشنواره کار شدند. یعنی ما تیر ماه خبر داشتیم از این که در استانی پذیرفته شدیم ولی ظاهرا قوانینی که روی جشنواره حاکمه، ایجاب می‌کرد که تا زمان شروع جشنواره سال بعد خبری ازش کار نشه. خلاصه بگذریم. ما دو تا هم خوشحال و سرخوش گفتیم که فرداش می‌ریم آموزش پرورش.
در آموزش و پرورش، بیش از گذشته تحویلمون گرفتند! این بار به ما گفتند که نیازه تا فیلمی بگیریم که هردو توش باشیم (البته ما دو فیلم مجزا گرفتیم. چرا که رضا بیشتر روی جنبه UI و ظاهری قضیه کار می‌کرد و من روی بیس سیستم) و بعد یک پرپوزال دیگر بنویسیم که یک سری ملاحظات خاص رو درش رعایت کرده باشیم. این ملاحظات شامل نحوه فهرست‌بندی، استفاده از فونت و … بودند. خلاصه ما دوتا CD و یک کتابچه تحویل دادیم و بعدش مدت نسبتا طولانی، از هم دور شدیم.
جشنواره خوارزمی کشوری
مرداد ماه بود و من به همراه مادرم چند روزی (فکر کنم دو هفته!) آمدیم تهران. در همین روزها، یادمه که رضا به من زنگ زد. بهش گفتم چه خبر؟ چه کارا می‌کنی؟ و خیلی عادی حرف زد. برای من این موضوع خیلی جالب بود که چطور تونسته بود اونقدر خونسرد باشه و یهو من رو غافلگیر کنه :)) پای تلفن به من گفت که «فلانی زنگ زد و گفت که اوایل شهریور باید تهران باشیم که از پروژه دفاع کنیم.
خلاصه بعد برگشت من به بندر، قرار شد با رضا بریم و در مورد این پروسه بپرسیم. به ما گفتند که داورا اینطورین و باید چه کنید و … (که با تقریب خوبی البته درست نبود) و به ما پولی دادند که بلیت هواپیما تهیه کنیم و با هواپیما بریم تهران. همچنین بودجه‌ای به ما دادند که لباس‌های متحدالشکل تهیه کنیم و ما هم دوتا پیراهن گرفتیم که لعنت خدا هم گرونش بود، ولی سال ۹۱ بابت هر پیراهن ۶۰ هزار تومان پول دادیم 😂.
خلاصه ۵ شهریور ۹۱ شد. ما رفتیم فرودگاه بندرعباس و سوار یک عدد ایرباس A300 هواپیمایی ماهان شدیم و به سمت فرودگاه مهرآباد تهران پرواز کردیم. در تهران هم مسول آموزش و پرورش هرمزگان (همون آقای میانسالی که کارهای ما رو انجام داده بود) آمد و ما رو به خوابگاه دانشجویی دانشگاه تربیت دبیری شهید رجایی برد. حقیقتا تا حد خوبی حالمون گرفته شد، چرا که به ما گفته شده بود برای ما هتل رزرو شده و از این دست چرت و پرتا. ولی خب ایرادی نداشت، فرداش روز بزرگی بود.
فرداش رفتیم. ظهر شد و دعوت شدیم که بریم داخل اتاق. داخل اتاق، سه‌تا آقا نشسته بودند که علی‌الظاهر، اساتید کامپیوتر همون دانشگاه بودند (اینجا این رو بگم که بعدا روش بحث صورت بگیره، اگر جشنواره خوارزمی یک جشنواره کشوریه، آیا بهتر نیست که فراخوانی زده شه و از اساتید و صاحب‌نظران کل کشور خواسته شه که داوطلب بشن؟ چرا فقط یک دانشگاه خاص؟) و یک سری سوال پرسیدند. ما وقتی داشتیم صحبت می‌کردیم و …؛ من اشاره کردم که جبیر مبتنی بر گنو/لینوکس ساخته شده. یادمه یکی اونجا خندید و گفت «پس مثل همون لینوکس فارسیه‌ست…».
حالا شما خودتون حساب کنید که این که این دوستان زده بودند تو کانال مسخره‌بازی، چقدر به ما فشار آورد. خلاصه ما ارائه و دفاعمون رو تحویل دادیم و آمدیم بیرون. ناهاری بر بدن زدیم و کمی تهران‌گردی کردیم و بعدش هم رفتیم سمت فرودگاه. دقیقا یادمه بعد از این که مسول آموزش پرورش ما رو ترک کرد، ما کاری نداشتیم که انجام بدیم پس با رضا نشستیم به خوندن آموزش Bash و اسکریپت‌نویسی 😁
خلاصه به سمت بندرعباس برگشتیم و بعد از اعلام نتایج، فهمیدیم که رتبه قابل قبولی در این جشنواره کسب نکردیم. این خودش یک شکست بسیار بسیار بزرگ برای ما محسوب می‌شد. گرچه کادر مدرسه تاکید داشتند سال بعدش هم شرکت کنیم ولی حقیقتا ما سال بعد تصمیم داشتیم دیگه شرکت نکنیم و همین هم شد. این دقیقا اینجا به این معنا بود که پروژه هم داره تا حد خوبی به آخرای خودش نزدیک میشه.
رفتن روی BSD، بزرگترین اشتباه
هنوز که هنوزه، من سیستم‌عامل FreeBSD رو به شدت دوست دارم و محاله وقتی نسخه جدید میده، نصبش نکنم و باهاش کمی بازی نکنم. اما حقیقت امر این بود که BSD ها – به جز مک – واقعا برای استفاده دسکتاپ و روزمره مناسب نیستند. حتی روی سرور و روتر و … (که BSDها حرف‌های به شدت زیادی برای گفتن دارند) هم معمولا انتخاب خوب و اول نمی‌تونن باشند.
یکی از مهم‌ترین دلایل، اینه که BSDها معمولا ساپورت سخت‌افزاریشون اونقدری که باید و شاید، خوب نیست. دلیل دیگری که به ذهنم می‌رسه اینه که استفاده از BSDها به شدت محدوده و بین هزاران شرکت و استارتاپی که مبتنی بر لینوکس هستند، شاید فقط Netflix, WhatsApp و Sony باشند که از FreeBSD (یا نسخه‌های دیگر BSDها) استفاده کنند. همین امر، باعث شده که BSDها مستندات کمتر و جوامع کوچکتری داشته باشند.
و البته اشتباه دیگری که داشتم این بود که فکر می‌کردم اگر برم روی BSD و یه بخش خوبی از رابط کاربری هم خودم بسازم (که تاحدی این کار رو کرده بودم) و مجوز اون هم BSD قرار بدم، شاید بتونم کد رو ببندم. اما هیچ کس نبود بهم این نکته رو گوشزد کنه که بستن کد برای پروژه‌ای که تیم کوچکی داره و ساپورت مالی نمیشه و سرمایه‌گذار خاصی هم نداره، سم مطلقه.
خلاصه با پیاده‌سازی نه چندان بد، تفکرات اشتباه و صد البته واکنش‌های عجیب و غریب جوامع نرم‌افزار آزاد و متن‌باز ایران، این پروژه باز بیشتر و بیشتر روی سراشیب سقوط قرار گرفت. اما حقیقت امر اینه که یکی از بزرگترین تیرهای خلاص این قضیه رو، همین جامعه نرم‌افزار آزاد به این پروژه وارد کرد.
واکنش‌های جامعه نرم‌افزار آزاد ایران و پیامدهایش
من اصلا دوست ندارم در نقش قربانی فرو برم و شکست‌ها و عدم موفقیتم رو گردن کسی بندازم. حقیقتا از این رفتار به شدت بدم میاد و اگر ببینم کسی چنین رفتاری داره خیلی سریع، از دایره دوستی و حتی آشنایی من ممکنه حذف بشه. پس امیدوارم این بند خاص از مطلب من، این حس رو القاء نکنه که در نقش قربانی فرو رفتم.
بگذریم، جامعه نرم‌افزار آزاد ایران، که در حال حاضر عمدتا حول اوبونتو و در فروم اوبونتو متمرکز شده تقریبا (و این تمرکز هم خودش سم مهلکیه) رفتارهای عجیب و جالبی دارند. این جامعه عموما اینطوری بود که خیلی سخت افرادی که بیرون گود بودند رو می‌پذیرفت و خیلی وقت‌ها هم نمی‌تونستند یک سری موضوعات خاص رو بپذیرند. به همین دلیل، رفتارها بیشتر شبیه گنگسترها و یاکوزاها می‌شد. حقیقتا در مقابل پروژه جبیر هم تا حد زیادی به این شکل برخورد نشان دادند.
برخوردهایی از این دست که «چرا به فلان پروژه کمک نمی‌کنی؟» اصلا از نظرم بد نیست. خیلی هم خوبه و خیلی راحت میتونه شما رو مجاب کنه که نیاز نیست چرخ رو از اول اختراع کنید. اما خب، گاهی برخوردها سمت ترولینگ و قلدری سایبری پیش می‌رفت. مثلا شخصی میومد می‌گفت «بیا کرنل رو بکن داروین» و بعد چند نفر ادامه می‌دادند. نکته جالب هم این که از سادگی من هم به عنوان یک نوجوان، تا حد خوبی بهره‌کشی شده بود اینجا. من الان دانشی دارم که بهم میگه که تعویض کرنل بسیار سخته، و در بعضی موارد کاملا ناممکن. اما اون موقع من چنین آگاهی‌ای نداشتم.
خلاصه بگم که کم کم به جایی رسید که من دیگه می‌فهمیدم کجاها ملت دارند دستم میندازن. حقیقتا خوشم اومده بود که خودم همراه شم با این قضیه و تا می‌تونم چرت و پرت ببافم. اما خب حقیقتا این به ضرر من شد چرا بعدتر، برچسب ترول به من چسبید و از جامعه کاملا پاک شد. جامعه‌ای که تقریبا همیشه نشون داده با افراد جدید – صرفنظر از این که آدم‌های خوبین یا بد – چنین برخوردی رو داشته و خب این برخوردها، نتایج خوبی هم نداشته. برای مثال، خود من از سال ۹۳ تا ۹۶ واقعا در این جامعه هیچ حضور فعالی نداشتم و ۹۶ دوباره برگشتم بهش. سال ۹۹ هم موارد مشابهی پیش آمد و دلخوری‌هایی ساخته شد.
خلاصه بگذریم از این موضوع، می‌خواستم صرفا این موضوع رو شفاف کنم که جامعه، از دور ممکنه قشنگ به نظر برسه اما خب درونش نیازمند سازگاری بالا و همرنگ جماعت شدنه. حقیقتا من هم شخصی نیستم که بخوام همرنگ جماعت باشم، به همین خاطر ممکنه در جوامع مختلف، متضرر بشم 😁
سخن آخر
اول از همه از شما ممنونم که این مطلب رو خوندید و تا اینجا اومدید. دوم، میخوام ازتون دعوت کنم که علاوه بر این وبلاگ، ویرگول هم میتونید مطالب من رو بخونید ولی در ویرگول معمولا انقدر حرافی نمی‌کنم 🙂 و در نهایت، میخوام یک جمع‌بندی کلی روی این سه قسمت بکنم و بگم که به پایان آمد این دفتر، حکایت همچنان باقیست.
حقیقتا بعد از شکست پروژه جبیر، من یک درس بزرگ گرفتم. درسی که بهم گفت «نیاز نیست استیو جابز دوم باشی، تو خود خودت باش» و این درس به نظرم بزرگترین نکته شخصیتی بود که می‌تونستم از انجام چنین پروژه‌ای دریافت کنم. درس و نکته بعدی هم این بود که حرف‌های اطرافیان میتونه به شدت روی روان آدم تاثیر بذاره و نباید گذاشت این حرف‌ها، از ما یک موجود کینه‌ای بسازه که بعدتر نیازمند انتقا‌م‌گیری و پرونده‌سازی و فلان باشه. درس‌های شخصیتی و روانی این پروژه، واقعا برای من مهم و ارزنده بودند.
از نظر فنی هم، درس‌های خوبی گرفتم. برای مثال اندازه افرادی که LPIC 1, 2 می‌گذرونند از لینوکس یاد گرفتم. تا حد خوبی پایتون یاد گرفتم. حتی همین امر باعث شد که بعدتر، روبی یاد بگیرم و … . همچنین یاد گرفتم که نیاز نیست برای متفاوت بودن حتما به سمت BSD رفت بلکه یک رابط کاربری متفاوت هم میتونه به خودی خود، تا حد خوبی تاثیر مثبت روی ذهن افراد داشته باشه.
از منظر بیزنسی هم بخواهیم نگاه کنیم یک درس خیلی خوب گرفتم. اون این که «وقتی تیم کوچیکه یا پروژه تک‌نفره جلو میره نیازی نیست که کد، بسته باشه. اتفاقا باز بودن کد به نفع توئه». و همین باعث شد از اون به بعد عمده پروژه‌های من روی گیتهابم قرار بگیرند.
خلاصه که یک پروژه شکست‌خورده، میتونه پر از درس برای ما باشه. مهم اینه که ما بخواهیم همیشه در سوگ بمونیم؟ یا این که به قدری سوگواری کنیم و بعد از اون سوگواری به سمت انجام یک پروژه جدیدتر قدم برداریم. نمی‌دونم فیلم Whiplash رو دیدید یا نه، اما در صحنه‌ای یکی از شخصیت‌ها میگه «چارلی پارکر وقتی با اون صحنه مواجه شد، اول سوگواری کرد. بعد یک روز کامل استراحت کرد و بعدش اونقدر تمرین کرد که ما امروز ازش حرف بزنیم». پس باید گفت که این ماییم که انتخاب می‌کنیم چارلی پارکر باشیم، یا اون نوازنده‌ای که با یک شکست، کلا ساز و نوازندگی رو میذاره کنار.
در پایان، مجددا از شما بابت وقتی که برای خوندن این مطلب گذاشتید تشکر می‌کنم. همچنین امیدوارم که این تجربه شکست طولانی، تونسته باشه برای شما جرقه یا کمکی باشه در هندل کردن پروژه‌هاتون یا حداقل بهتون کمک کرده باشه که چطور با پروژه‌های شکست خورده کنار بیایید. امیدوارم که در آینده نزدیک، بتونم با مطالب بیشتری در خدمت شما باشم.
احتمالا اگر وبلاگ یا محتوایی که من تولید می‌کنم رو دنبال کرده باشید، با مفاهیم و اسامی خاصی من رو به یاد خواهید آورد. چه مثل چند ماه اخیر با پروژه‌های بینایی ماشین ، چه روبی و ریلز که چندین ساله کم کم با اون شناخته میشم، چه لینوکس و سخت‌افزار و این داستان‌ها. احتمالا هم اگر از دنبال‌کنندگان این وبلاگ باشید، می‌دونید که داستان برنامه‌نویس شدن من (قسمت اول، قسمت دوم) چیه و چطور شد که من شدم اینی که هستم.
اما قطع به یقین، خیلی از دوستان قدیمی‌تر من رو با «پروژه جبیر» یا «جبیر او اس» یا «سیستم‌عامل جبیر» می‌شناسند. پروژه‌ای که من رو با جدیت وارد دنیای توسعه نرم‌افزار، نرم‌افزار آزاد و جامعه کاربری گنو/لینوکس ایران کرد. در این پست، قصد دارم تا در مورد پروژه جبیر کمی بنویسم. در واقع، قصد من اینه که داستان این پروژه رو تعریف کنم و بگم که چی شد که اینطوری شد 🙂
چرا این مطلب نوشته شد؟
حقیقتا از سال ۹۴ به بعد که دیگه وبسایت پروژه جبیر آپدیت نشد و حتی از برند جبیر برای پروژه‌ای استفاده نشد، دلم نخواست که راجع بهش چیزی بنویسم. چرا که این پروژه علیرغم تمام خوبی‌ها و آموزه‌هاش برای من، خاطرات بدی هم داشت و خب هرچیزی، لازمه که روزی کنار گذاشته بشه. در حقیقت، جایی که انسان حس می‌کنه باید رها کنه، باید رها کنه و برای من این زمان سال ۹۴ بود. زمانی که همه‌جا اعلام کردم پروژه جبیر، چه در قالب «توزیع لینوکس» و چه در قالب «نسخه‌ای از BSD» دیگر عرضه نخواهد شد.
اما چندی پیش، پای یکی از پست‌های جبیر (لینک) نظری دریافت کردم (که البته تایید نشده) و در بخش آمار وبگاه (که به کمک افزونه Jet Pack بررسی می‌کنم) هم متوجه شدم که افرادی هستند که در حال رصد کردن گذشته من هستند. یکی از چیزهایی که عمیقا بهش باور دارم اینه که نباید در گذشته افراد زیاد کند و کاو کرد، چرا که تهش شما یا خودت ضایع میشی یا چیزی که دنبالش می‌گردی چیزی در حد زیربغل مار خواهد بود. پس با این حساب، تصمیم گرفتم که در یک سلسله مطلب جامع، داستان جبیر او اس رو جمع کنم.
حالا وقت اینه که حدودا ده سال در زمان سفر کنم و برسیم به سال ۸۹-۹۰ که این پروژه رو استارت زدم، بگم چی شد که این پروژه به ذهنم رسید و چطور شد که رفتم سمت لینوکس و … .
جرقه‌های اولیه
بسیاری از افرادی که من رو می‌شناسند، از ارادتی که نسبت به استیو جابز دارم، خبر دارند. سال حدود ۸۹ بود و من در مجلاتی که اون زمان به صورت روتین از قیمت فلان گوشی و فلان کامپیوتر و فلان کارت گرافیک می‌نوشتند از رونمایی از محصولات جدید اپل مثل iPhone 4 یا iPad می‌خوندم. بعد مدتی، با استیو جابز و زندگی اون آشنا شدم و فهمیدم که این بابا، آدمی بوده که خیلی خیلی از صفر شروع کرده (تقریبا بر خلاف خیلی از ابرپولدارهای سیلیکون‌ولی، ایشون اصلا خونواده متمول و حتی اهل فنی نداشته و خونواده‌ای که درش رشد کرده بوده یک خونواده خیلی معمولی بوده).
خلاصه آشنایی با استیو جابز، بعدش خریدن یک iPod Touch 3G در من جرقه‌ای روشن کرد. جرقه‌ای مبنی بر این که «من باید دنیا را تغییر بدم». تغییر دنیا، کار سختیه. خیلی از ما جایی از زندگی این قصد رو داشتیم ولی کار خاصی براش نکردیم. خیلی‌ها هم حرکتایی زدیم ولی بعدا سرمون به سنگ خورده. خلاصه که خیلیامون اونقدری دیوانه بودیم که روزی بخوایم دنیا رو تغییر بدیم و به قول استیو جابز، افرادی که اونقدر دیوانن که فکر می‌کنن میتونن دنیا رو تغییر بدن، دقیقا همونایین که دنیا رو تغییر میدن.
در همون سالها بود که ما مهاجرتی از تهران به بندرعباس داشتیم و خب حقیقتا این مهاجرت و دوری از فضای تهران – بویژه محله‌ای که درش بزرگ شده بودم و طبیعتا بسیاری از هم‌کلاسی‌های دبیرستانم هم قرار بود همون بچه‌های راهنمایی و دبستان باشند – باعث شده بود کمی ناامید و افسرده باشم. تمام این دلایل دست به دست هم دادند که من تصمیم بگیرم که بخوام استیو جابز دوم باشم (شاید اشتباه همین بود، هوم؟).
خلاصه شبانه‌روز در حال ایده‌پردازی بودم. اما ایده‌ها همین جا متوقف نشدند. ایده‌ها خیلی بیش از اون چه که فکر کنید پیش رفتند در ذهنم. اما نیاز داشتم یک محرک خیلی اولیه داشته باشم. نمی‌دونستم چه محرکی ولی بهرحال یک محرک نیاز بود.
من باید سیستم‌عامل بسازم
بالاخره پیداش کردم. محرکی که لازم داشتم تا باهاش دنیا رو تغییر بدم، پیدا کرده بودم. شاید باورتون نشه ولی به معنای واقعی در نقطه نقطه بدنم شور و شوق رو حس می‌کردم و برای انجام این کار، انگیزه بسیار بسیار زیادی داشتم. حالا که این انگیزه بود، سوال اینجاست که چرا نه؟ اما قبل از هرچیزی بهتره ببینیم که این انگیزه چی بود.
نمی‌دونم شما چقدر با نشریات قدیمی آشنایید ولی نشریه مورد علاقه من، یا بهتر بگم یکی از نشریات مورد علاقه من، مجله دانشمند بود. مجله دانشمند مطالب علمی و فنی جالبی داشت. در اون می‌شد از ژنتیک و زیست‌شناسی تا هوش مصنوعی و … رو خوند و یاد گرفت و لذت برد. در بسیاری از شماره‌هاش، کارهای عملی رو توضیح می‌داد که شما می‌تونستید در خانه انجام بدید و … . خلاصه کلام که یکی از بهترین نشریاتی بود که می‌خوندم.
در تابستان ۸۹ یا ۹۰ بود که درست یادم نیست؛ در یکی از شماره‌های دانشمند کتاب «سیستم‌های عامل: طراحی و پیاده‌سازی» اثر «اندرو استوارت تنن باوم» معرفی شده بود. به صورت خلاصه بگم، در این مطلب اومده بود که انگیزه تنن‌باوم از نوشتن این کتاب چی بوده و چه فرایندی (بسته شدن کد منبع یونیکس نسخه ۷) باعث شد که سیستم‌عامل خودش رو از بیخ بنویسه و بعد از اون، شروع کنه به این که مراحل توسعه رو مستند کنه و در قالب یک کتاب برای دانشجویانش و همچنین علاقمندان عرضه‌ش کنه.
اما این کل ماجرا نبود. آخر این مطلب اشاره شده بود که این کتاب و این سیستم‌عامل (مینیکس) باعث شدند که دانشجوی فنلاندی بی‌اعصاب، یعنی لینوس تروالدز؛ برای این که بتونه با مینیکس درست و حسابی کار کنه و گروه‌های گفت‌وگو رو بخونه و … یه سری ابزار توسعه بده و در همین حین یک هسته هم از بیخ و بن بنویسه. در ادامه توضیح داده شد که لینوس تروالدز یک باره هاردش رو نابود کرد (و خب شاید این نابودی یک‌باره هارددیسک که در میان لینوکسی‌ها شایعه، از همین قضیه نشات بگیره 😂) و این نابودی باعث شد که سیستم‌عامل خودش – که ملغمه‌ای از ابزارهای پروژه گنو و کرنلش بود – رو روی دستگاهش نصب کنه.
در ادامه کمی به تاریخچه لینوکس و دعواهای روتین تروالدز با بقیه اشاره کرده بود. این بخش کاملا من رو شیر کرد. من این بند رو که خوندم (و دقیقا یادمه که داخل یک خودرو هم بودیم که من این مطلب رو خوندم) با صدای بلند گفتم که «من باید سیستم عامل بسازم» طوری که خونواده هم نگاهشون به سمتم برگشت. خلاصه که این شد که من تصمیم گرفتم که اولین پروژه خیلی جدی زندگیم، یک سیستم عامل دسکتاپ باشه.
نخستین مطالعات، نخستین پیاده‌سازی‌ها
خب من بعد از خوندن اون مطالب یادمه که کتابی به اسم «کلید لینوکس» که آموزشش بر مبنای «اوبونتو ۱۰.۰۴» بود رو خوندم و خیلی چیزا ازش یاد گرفتم. در عین حال، روی یک ماشین مجازی اوبونتو نصب کردم و کمی از آموزش‌هایی که از لینوکس دیده بودم بهره بردم که ببینم چه خبره و دنیاش دست کیه. بعد از اون خلاصه اینطور شد که یک روز تصمیم گرفتم اوبونتو ۱۱.۰۴ (یا دقیق یادم نیست، ۱۱.۱۰) رو روی لپتاپم نصب کنم و حین نصب کل دیتام هم پرید.
بعد از این نصب، شروع به این کردم که یاد بگیرم که چطور می‌تونم شخصی‌سازی کنم و تا حد خوبی هم موفق بودم. اما هنوز کلی علامت سوال در ذهنم بود. به همین خاطر، کاری که کردم این بود که وارد فروم اوبونتو شدم و این سوالات رو پرسیدم. این‌گونه بود که ماجرای عریض و طویل جبیر، آغاز شد …
این داستان ادامه دارد …
تا همین الان، این مطلب شدیدا طولانی شده. به همین خاطر این مطلب رو اینجا قطع می‌کنم و اجازه میدم که شما حدس بزنید باقی ماجرا چی شد. البته دروغ چرا، باقی ماجرا رو خیلی زود (شاید حتی فردا شب) در وبلاگ منتشر می‌کنم و منتظر بازخوردهای شما می‌مونم.
امیدوارم که این مطالب، اطلاعات خوبی به شما از روند یک پروژه اوپن سورس که از قضا در جاهای مختلفی به شدت اشتباه زده؛ بده و براتون مفید واقع بشه. از این که وقت گذاشتید و این مطلب رو خوندید، ممنونم.
در پست پیشین، یعنی قسمت اول داستان برنامه‌نویس شدنم (لینک) از زمانی که شروع به خوندن کتاب‌های ویژوال بیسیک کردم تا زمانی که پروژه جبیر رو راه انداختم رو به تفصیل توضیح دادم. فکر می‌کنم داستان برنامه‌نویس شدن من، داستان جالبی برای خیلی از دوستانی که وبلاگم رو میخونن بوده و به همین دلیل، تصمیم گرفتم که قسمت دومش هم حتما بنویسم.
همونطوری که در قسمت قبلی قولش رو داده بودم، قراره که در این قسمت از بعد از پروژه جبیر تا زمانی که وارد بازار کار شدم رو توضیح بدم و بگم چی شد که اینطوری شد. در مورد مسیرهای شغلی قبل‌تر توضیح دادم (مثلا در پست چگونه توزیع لینوکس بسازیم و یا پست چگونه بازی‌ساز شویم) همینطور حتی ابزارها و وسایلی که در مسیر شغل‌های مختلف طراحی و تولید کردم (مثل صداگذاری روی بازی کامپیوتری) هم در این وبلاگ پیش‌تر توضیح دادم. فلذا در این مطلب، اصلا و ابدا به مسیرهای شغلی اشاره نخواهم کرد.
ورود به دانشگاه
در طی این سالها، یعنی از حدود ۹۱ تا ۹۳ راه‌های زیادی رو رفتم که سرویس‌ها و نرم‌افزارهای خاصی رو طراحی کنم و خب دروغ چرا، تا حد زیادی هم رویای استیو جابز یا زاکربرگ شدن هم در سر داشتم و خب کارهای مختلفی مثل ایجاد انجمن‌های اینترنتی مختلف (ایران‌بی‌اس‌دی، ایران‌هکینتاش و …) گرفته تا برپا کردن شبکه‌های اجتماعی و نرم‌افزارهای آنلاین دیگر (اکسوال، نکست‌کلود و …) رو انجام می‌دادم. راستش این راه‌ها من رو به قول خارجی‌ها Satisfy نمی‌کرد و همچنان دنبال این بودم که یک سیستم عامل خوب بسازم!
خلاصه شد سال ۹۲ و ما از شهر بندرعباس به تهران برگشتیم. اون سال، سال پیش‌دانشگاهی من بود (و بد نیست این داستانکم رو هم پیرامونش بخونید) و اون سال، یک تصمیم بزرگ هم گرفتم. تصمیمم این شد که جبیر به جای این که مبتنی بر اوبونتو (یک توزیع از گنو/لینوکس)، یک نسخه شخصی‌سازی‌شده از FreeBSD باشه. از همین رو، شروع کردم به رفتن به IRC های مختلف، سوال پرسیدن و مستندات خوندن. بعد از چندین ماه مطالعه، وضعیت اینترنت خونه و خودم تا حد خوبی پایدار شد و بعد شروع کردم به انجام تغییرات روی کد FreeBSD.
بعد از مدتی، پروژه جبیر تا حد خوبی پیش رفت و گذشت و گذشت و من کنکور دادم (داستانی از کنکور هم اینجا نوشتم) و وقتی نتایج اومد، فهمیدم که در دانشگاه آزاد اسلامی واحد تهران مرکز در رشته مهندسی کامپیوتر و گرایش سخت‌افزار قبول شدم.
شرکت در لاگ‌ها و رویدادها و آخر و عاقبت پروژه جبیر
حضور در تهران و دانشجو شدن، به من کمک کرد که وارد جامعه بشم و در رویدادهای نرم‌افزار آزاد و متن‌باز و سایر رویدادها (مثل PyCon و …) شرکت کنم. اولین رویدادی که شرکت کردم، رویدادی بود به اسم «جامعه رایانش ابری آزاد». در اون رویداد با KVM و Docker آشنا شدم و تا حد زیادی هم دانشم در زمینه Containerها و مجازی‌سازی تا حد خوبی بالا رفت.
در حاشیه شرکت در این رویدادها، بسیاری از افرادی که از انجمن اوبونتو و یا تکنوتاکس یا لینوکس‌ری‌ویو می‌شناختم رو حضوری دیدم و باهاشون آشنا شدم و حتی رفاقت‌هایی شکل گرفت. پس از مدتی، در بحثی دوستانه، تصمیم بر آن شد که پروژه جبیر کلا منحل بشه و پروژه‌ای به این بزرگی که نیازمند دانش فنی بالا، پول زیاد و همچنین حوصله فراوونه، به زمانی موکول شه که بتونم از پس حداقل یک موردش بربیام. فلذا پروژه جبیر اعلام شد که دیگه قرار نیست ادامه پیدا کنه.
اگر دوست دارید ببینید که پروژه جبیر چه شکلی بوده، میتونید این لینک مربوط به وب آرکایو رو هم ببینید: لینک. در ادامه، بنا به دلایلی (که در ادامه این مطلب بهش می‌پردازیم) تصمیم شد که پروژه جبیر بیشتر روی فاز سخت‌افزاری باشه و چند مطلب هم در موردش حتی نوشتم(لینک).
یادگیری روبی، ورود به حوزه سخت‌افزار و دیگر هیچ!
مهرماه ۹۳ بود که من خیلی جدی تصمیم گرفتم حداقل یک زبان برای توسعه وب رو جدی یاد بگیرم. قبل‌ترش، کتاب «از این پس پایتون» رو خونده بودم و به همین خاطر هم کمی با پایتون و فلسک آشنا بودم. دوستی یک کتاب جنگو هم برای من ارسال کرد. اما در همون هنگام در بحثی در IRC که دقیق یادم نیست مربوط به occc بود یا لاگ کرج، دوستی به من پیشنهاد کرد که روبی و روبی‌آن‌ریلز رو یاد بگیرم. در ادامه‌ش، توصیه کرد که حتما با دیتابیس‌ها آشنا شم و کمی هم مهندسی نرم‌افزار یاد بگیرم.
من هم این توصیه رو عملی کردم و شروع کردم به خوندن روبی. شاید باورتون نشه ولی از اونجایی که دیدم زبون روبی، خیلی در ایران زبون روتینی نیست و خیلی‌ها باهاش غریبه‌ند، تصمیم گرفتم دانش خودم رو در قالب یک کتاب الکترونیکی دربیارم و خب نتیجه پس از مدت نسبتا طولانی شد کتاب آموزش روبی که به رایگان قابل دانلوده.
خب همونطوری که ابتدای متن گفتم، من گرایش سخت‌افزار بودم و حقیقتا این وسط به سرم زده بود دانش سخت‌افزاری خودم رو هم بالا ببرم. به همین خاطر ترم ۳ یا ۴ که بودم، قبل از این که به مدار منطقی برسم، خودخوان شروعش کردم. برام جالب بود و خب در عین حال ریاضیات گسسته هم برای من داشت مرور می‌شد. این مرور، در کنار دانش مدار منطقی من رو وادار کرد که کمی بیشتر بخوام در این حوزه ورود کنم. به همین خاطر، معماری کامپیوتر و ریزپردازنده رو هم حتی پیش از این که درسم بهشون برسه، مطالعه کردم.
وقتی به نتایج جالبی رسیدم، تصمیم گرفتم دوباره دانشم رو با مردم به اشتراک بذارم. به همین خاطر، این بار هم محتوا رو به زبون انگلیسی تولید کردم (لینک) و به رایگان در نسخه انگلیسی همین وبلاگ منتشرش کردم. خلاصه که اینجا تموم نمیشه. در اون سالها، بازار «اینترنت چیزها» یا IoT هم داغ بود و خب طبیعتا شروع کردم به یادگیری آردوینو، رزبری‌پای و … و پروژه‌های جالبی هم با اونها انجام دادم. البته خیلی از این پروژه‌ها رو هنوز که هنوزه عمومی نکردم.
خلاصه این مورد هم گذشت و رسیدیم به شهریور ۹۶. یعنی جایی که من خیلی جدی و رسمی وارد بازار کار شدم.
ورود به بازار کار
در تیرماه ۹۶، در رویدادی شرکت کردیم که مرتبط با فعالان صنعت بازی رایانه‌ای بود. این رویداد، به طور خاص به آهنگسازان و مهندسین صدا اختصاص داشت و خب بخاطر علاقه شخصیم به موسیقی، در این رویداد شرکت کردم. آخر رویداد گپ و گفتی با سخنران رویداد داشتم که باعث شد شخصی بیاد خودش رو معرفی کنه و بگه که تیمشون نیاز به آهنگساز داره. پس از مدتی، مدیر استودیو به من پیام داد و گفت بازی‌ای در ژانر کودکه و خب نمی‌دونم چی شد که اون موقع، این بحث ادامه پیدا نکرد.
اما شهریور ۹۶ یکی از دوستانی که در همون استودیو مشغول بود، برای یک بازی دیگر من رو دعوت کرد به همکاری. یک مصاحبه ریزی داشتیم و پس از اون مصاحبه، قرار شد من برم و همکاری کنم. پس از این ماجرا، من رسما وارد اکوسیستم و بازار کار شدم تا به امروز.
سخن آخر
خب، در این مطلب هم مثل مطلب قبلی حجم خوبی از خاطرات من رو شاهد بودید. کل حرفی که می‌خواستم بزنم این بود که دوستان، از تجربه کردن و حتی شاخه شاخه پریدن؛ نترسید. این پرش‌ها به خودی خود باعث میشن که شما در کارتون – حتی کارهای فریلنسری و پروژه‌ای – به شدت موفق‌تر عمل کنید. یادتون باشه که زندگی، فان‌تر از اونیه که بخواید با زیادی جدی گرفتن؛ خرابش کنید.
خیلی از افرادی که این روزها، میخوان پروژه‌هایی در حوزه‌های مختلف هوش مصنوعی مثل یادگیری ماشین، یادگیری عمیق، علوم داده و … انجام بدن یک گلوگاه بسیار بزرگ دارند و اون «داده» است. خیلی‌ها واقعا نمی‌دونن از کجا میتونن داده‌های مناسب پروژه‌هاشون به دست بیارن. در این مطلب، قراره که این موضوع رو پوشش بدم.
منابع مناسب داده برای پروژه‌های شما
در این بخش، با هم چندین منبع مناسب برای پیدا کردن داده رو بررسی خواهیم کرد. فقط قبل از هرچیز این رو بگم که این منابع میتونن تغییر کنن در طول زمان پس هرچه که در این مطلب بیان شده رو در مرداد ۱۴۰۰ معتبر بدونید و اگر مدتی بعد از انتشار این مطلب دارید مطالعه‌ش می‌کنید، با جست‌وجو و پرس‌وجو در مورد این منابع، اطلاعات به‌روزتر دریافت کنید.
Kaggle
وبسایت کگل، یک محیط تقریبا مشابه شبکه‌های اجتماعی برای دانشمندان داده و متخصصین هوش مصنوعی به حساب میاد. در این وبسایت شما میتونید مجموعه داده (Dataset) های خوبی رو پیدا کنید. همچنین، میتونید کارهایی که ملت روی اون داده‌ها انجام دادن رو در قالب Kaggle Kernel (به نوعی همون جوپیتر نوت‌بوک خودمون) ببینید و یا کارهای خودتون هم به اشتراک بذارید.
برای دسترسی به کگل، میتونید روی این لینک کلیک کنید.
Academic Torrents
این وبسایت هم وبسایت جالبیه (و به نوعی مرتبط با بخش بعدی). در واقع هر حرکت آکادمیکی که زده شده و اطلاعاتش هم همزمان منتشر کردند رو در خودش داره. چرا؟ چون جست و جو در محتوای آکادمیک نسبتا سخته و این وبسایت اون کار رو براتون راحت کرده. همچنین یک بخش خوبی برای مجموعه‌داده (لینک) هم در این وبسایت در نظر گرفته شده.
برای دسترسی به این وبسایت، میتونید از طریق این لینک اقدام کنید.
وبسایت دانشگاه‌ها
همونطوری که در بخش قبلی گفتم، بسیاری از دانشگاه‌ها (و در کل، فضاهای آکادمیک) تحقیقات زیادی انجام میدن و داده‌های اون تحقیقات رو هم معمولا منتشر می‌کنن. چرا که یکی از اصول مطالعات آماری، اینه که داده‌ها به صورت شفاف منتشر بشن (شاید دلیلش اینه که بعدها، یکی بخواد خودش اون آزمایش و مطالعه رو تکرار کنه و …).
به همین خاطر، وبسایت دانشگاه‌ها – چه ایرانی و چه خارجی – میتونه محل خوبی باشه برای مراجعه و پیدا کردن داده‌های خوب برای مطالعه.
دیتاست‌های متن‌باز شرکت‌ها
بسیاری از شرکت‌های بزرگ مثل گوگل، فیسبوک، آمازون و …، میان و حجم خوبی از داده‌هایی که قبل‌تر در تحقیقاتشون استفاده کردند رو به صورت اوپن‌سورس، منتشر می‌کنن. پیدا کردن این دیتاست‌ها هم اصلا کار سختی نیست.
برای مثال، در این لینک میتونید دیتاست‌های گوگل رو ببینید. یکی از نمونه‌هایی که خود گوگل اینجا مطرح کرده، دیتاست مرتبط با بیماری کووید-۱۹ است. (لینک)
چرا این شرکت‌ها، دیتاست‌ها رو منتشر می‌کنن؟ باز هم میگم دقیقا به همون دلیلی که دانشگاه‌ها منتشر می‌کنن. شاید افراد یا سازمان‌هایی باشن که بخوان تحقیقات و مطالعات رو برای خودشون تکرار کنند و یا نتیجه آزمایشات و … رو صحت‌سنجی کنند.
خزیدن (Crawling) صفحات وب
خب، بعضی وقتا هم داده‌ای که ما نیاز داریم، توسط شرکت‌ها یا دانشگاه‌ها منتشر نشده. پس در این حالت چه کار می‌کنیم؟ اگر داده مورد نظر، در اینترنت موجود باشه، میتونیم یک خزنده (Crawler) بسازیم و با اون کارمون رو پیش ببریم.
در بسیاری از زبانهای برنامه‌نویسی و چارچوب‌هاشون، ابزارهای بسیار خوبی برای کراول کردن صفحات وب وجود داره. یکی از بهترین نمونه‌هاش میتونه BeautifulSoup در پایتون باشه. در مطالب بعدی، احتمالا با استفاده از این ابزار، یک خزنده برای وبسایت‌های مختلف خواهیم نوشت.
دوربین، میکروفن، حرکت!
اگر داده‌های مورد نیاز ما حتی به شکلی که بتونیم کراول کنیم موجود نبود چی؟ ساده‌ست. ابزارهای ورودی خوبی برای کامپیوتر وجود داره که میتونه بهمون کمک کنه تا داده مورد نظر رو جمع‌آوری کنید.
گذشته از این، دوربین تلفن‌های همراه، میتونه منبع خوبی باشه برای جمع آوری تصاویر(پروژه‌های بینایی ماشین و …)، میکروفن‌های استودیویی برای دریافت صدا خوبن. اگر نیاز به دیتایی مثل گرما یا رطوبت نیاز دارید، طراحی مداری که این داده رو از محیط بخونه و روی دیتابیس خاصی ذخیره کنه کار سختی نیست.
جمع‌بندی
پروژه‌های هوش مصنوعی به ذات سخت نیستند. چیزی که اونها رو سخت می‌کنه، همین دیتای ورودی و تمیزکاری و مرتب کردنشه. بعضی وقتا داده‌های ما کم هستند و ما مجبور خواهیم شد که Data augmentation انجام بدیم. بعضی وقتا ممکنه نویز به قدری زیاد باشه که اصلا مرحله جمع‌آوری دیتا رو مجبور بشیم دوباره از نو انجام بدیم و … .
خلاصه هدف از این مطلب این بود که اگر پا در این عرصه گذاشتید، بدونید همیشه جایی هست که بتونید بدون مشکل، داده‌هایی رو دریافت و در پروژه‌تون استفاده کنید و از بابت نویز و …، خیالتون تا حد خوبی راحت باشه.
در دنیایی زندگی می‌کنیم که متاسفانه یا خوشبختانه، عمده اطلاعات ما روی اینترنت هستند. در توییتر اسم و عکسمون روی پروفایله و از روزمرگی‌های زندگیمون می‌نویسیم. در اینستاگرام لحظات غم و شادی خودمون رو به اشتراک می‌ذاریم. در ساندکلاد صدای خودمون یا سازمون رو به رخ دیگران می‌کشیم. در لینکدین اطلاعات کار و تحصیل و … رو قرار دادیم. بسیار هم خوب، اما این داده‌ها و اطلاعات، آیا ممکن نیست علیه خودمون استفاده شه؟
جواب به سوال بالا «بله» است. احتمالا شما هم از پدر و مادرتون زیاد شنیدید که «ملت گرگن» و باید گفت که بله، اینترنت پر از گرگ‌هاست. گرگهای اینترنت اما متفاوت از گرگهای اون بیرونن. گرگهای اون بیرون، معمولا تا وقتی سمتشون نرید گاز نمی‌گیرن، معمولا تا وقتی همکارشون نشید زیرابتون رو نمیزنن و … . اما گرگهای اینترنت چی؟ گرگهای اینترنت از هیچ فرصتی برای کسب اطلاعات در مورد شما و اذیت و آزار شما از اون طریق، دریغ نخواهند کرد. در این پست، قراره که با فرایند «مهندسی اجتماعی» آشنا بشیم و بعد یک سری راهکار برای مقابله باهاش ارائه کنیم.
اتصال نقاط، ساده‌ترین روش مهندسی اجتماعی
چند وقت پیش، در مورد امنیت بیت‌کوین و معاملاتش داشتم مطالعه می‌کردم. یک نکته جالبی برخوردم که بد نیست شما هم در موردش بدونید. شخصی که مطلب رو نوشته بود (متاسفانه با کامپیوتر قدیمی‌تری مطلب رو خوندم و در هیستوری مرورگرم نیافتمش، وگرنه پیوند می‌دادم) اینطور بیان کرده بود که:
درسته که بلاک‌ها و تراکنش‌ها رمز شدند و ما روی حریم خصوصی این نوع ارز حساب ویژه باز کردیم، اما یادتون باشه که مردم نقطه‌ها رو به هم وصل می‌کنن.
حالا، بیاییم ببینیم که این «نقطه»ها چین؟ ما چطور میتونیم به هم وصلشون کنیم؟ چرا اتصال نقاط مهمه و … . اول از همه، بیایید صرفا چندتا نقطه رو ببینیم:
سلام، من فلانی هستم.
من سال ۹۳ رفتم دانشگاه.
من کامپیوتر خوندم.
در یک بحثی مرتبط با یکی از دانشگاه‌های مطرح کشور (بیایید بگیم دانشگاه X)، من ورود کردم و از استادی، نقل قول کردم یا از استادی بد گفتم.
در لینکدین من، مشخصه که کجا کار می‌کنم اما محل تحصیلم رو مشخص نکردم.
از آب و هوای یک منطقه خاص در ایران تعریف و تمجید کردم.
حالا این داده‌ها رو داریم. چطور میتونیم ازش به اطلاعات بدرد بخوری برسیم؟ خب کاری نداره. بیایید در وصل کردن نقطه‌ها با من همراه شید و ببینید چقدر ترسناکه 🙂
وقتی گفتم «من فلانی هستم» احتمالا به اسم شناسنامه‌ایم، لقبم، اسم مستعارم یا یکی تو این مایه‌ها اشاره کردم. وقتی گفتم سال ۹۳ رفتم دانشگاه، شخص میتونه حدس بزنه که من از اکثریتی بودم که ۱۸ سالگی رفتند دانشگاه پس احتمالا متولد ۷۵ باشم، اما بعضی وقتا (برای آقایان) دانشگاه رفتن بعد از خدمت سربازی اتفاق می‌افته، پس اینجا بهتره که در نظر بگیرید که رنج تاریخ تولد بین ۷۳ تا ۷۵ بوده.
در مورد رشته تحصیلیم صحبت کردم. البته رشته تحصیلی گهگاهی از محتوای تولیدشده روی اینترنت هم قابل حدسه، گاهی هم از بحث‌هایی که افراد با دیگران می‌کنن و به اسم اساتید یا دروس خاصی اشاره می‌کنن. مثلا اگر در بحثی اشاره به «الکترونیک دیجیتال» شده باشه، احتمال خیلی خوبی داره که شخص «مهندسی کامپیوتر گرایش سخت‌افزار» رو در دانشگاه خونده باشه. پس به این شکل، میتونیم رشته تحصیلی فرد هم دربیاریم.
بعد از این، می‌رسیم به بحث در مورد محل تحصیل. در لینکدین شخص، نتونستیم چیزی پیدا کنیم. اما مثلا اومده و گفته «استاد چاکراهی در دانشگاه X از اون عوضیاس که دومیش خودشه». این که شخصی انقدر دقیق یک استاد رو بشناسه، با لفظ استاد صداش کنه و یا اشاره‌ای به سابقه آکادمیکش کنه، نشان از اینه که اون شخص احتمالا در محل تدریس اون استاد تحصیل کرده. به این شکل اطلاعات بسیار دقیق تحصیلی هم داریم. یک جمع‌بندی از این سه پاراگراف بکنم؟ من الان می‌دونم «فلانی، متولد فلان سال، فلان رشته رو در فلان دانشگاه خونده».
و اما در مورد آخرین نقطه. صحبت در مورد مکان‌ها، معمولا توسط کسی صورت می‌گیره که اشرافی به اون مکان داره. پس چه اتفاقاتی ممکنه بیفته؟ ساده‌ترینش اینه که حدس هکر به سمت این بره که شما ساکن اونجایید. ممکنه مشخص نشه که ساکن اونجایید، اما شما گوشی رو دست شخص دادید که روی منطقه‌ای خاص اشراف دارید و اونجا رو به خوبی می‌شناسید. پس در اون منطقه قطعا آمد و شدی دارید.
حالا اینا به کنار، چرا باید روی «اتصال نقطه‌ها» انقدر حساس باشیم؟ به فرض که طرف دونست شما چه‌کاره‌اید و کجا زندگی می‌کنید، خب تهش که چی؟ در ادامه بررسی می‌کنیم.
اتصال نقطه‌های مختلف به هم، این شرایط رو فراهم می‌کنه
در موارد حساس (مثل امنیتی شدن جو کشورها، حساس شدن مسئولین یک شرکت یا سازمان روی موضوعی خاص و … ) میتونه به شناسایی راحت شما کمک کنه.
شما رو در معرض آسیب‌های روانی (باجخواهی، پرونده‌سازی و …) قرار بده.
احتمال آسیب فیزیکی رو ببره بالا.
این رو در نظر داشته باشید. حالا بیایید بریم سراغ راه‌هایی که مهندسی اجتماعی میتونه حتی راحتتر هم باشه. من بهش میگم «مهندسی اجتماعی تعاملی».
مهندسی اجتماعی تعاملی
در مهندسی اجتماعی تعاملی، هکر اتفاقا آدم ناامن و زاغ‌سیاه‌چوب‌زنی نیست! بلکه دقیقا یکیه که با شما تعامل داره. این تعامل به روش‌های زیر میتونه انجام شه:
ساخت حساب کاربری و کسب شهرت در شبکه‌های اجتماعی
ساخت حساب کاربری با نام و مشخصات جعلی در شبکه‌های اجتماعی و پیام‌رسان‌ها و ایجاد روابط دوستی با دیگران
ساخت صفحات جعلی از وبسایت‌های خبری، صفحه ورود شبکه‌های اجتماعی، فرم‌های تماس و … .
انتشار اخبار جعلی
در خواست کمک‌های نقدی (در قالب ارزهای رایج، رمزارز و …)
حالا اینها هرکدوم چطور کار می‌کنن؟ بسیار هم خوب. بیایید در ادامه بررسیشون کنیم.
ساخت حساب‌کاربری و کسب شهرت در شبکه‌های اجتماعی
خواه‌ناخواه بسیاری از حرفهایی که ما می‌زنیم، میتونه تاثیر خوبی در «بالا آمدن» و مشهور شدن اشخاص دیگر داشته باشه. کافیه که شخصی که دیتا میخواد با ترفند‌هایی مثل «فالو کنید بک میدم» یا «منشن بده بگو اسم عمه کوچیکت چند تا ر داره» و …، یک پایگاه خوبی از آدمها رو میسازند. حالا ممکنه فکر کنید که «مشکلش چیه؟» به ذات مشکلی نداره. هر انسانی نیاز طبیعی به توجه و روابط انسانی داره و این حق طبیعیشه. حتی خیلی از این اینترکشن‌ها جالب و جذابن و به نظرم شرکت درشون میتونه خوش‌گذرانی کوتاه‌مدت خوبی باشه.
مشکل اصلی، زمانی رخ میده که این روش، میشه وسیله‌ای برای اقدامات بعدی. مثل چی؟ مثل انتشار خبرهای جعلی و یا کلاهبرداری و سوءاستفاده‌های متعدد از افراد. همین الان از افرادی که شناخته‌شدگی خوبی در دنیا دارند (مثل خواننده‌ها، بازیگران، فوتبالیست‌ها و …) خبرهایی مثل آزار جنسی یا ایجاد مزاحمت کم نیست! فلذا بهتره که حواسمون جمع باشه که چه کسانی رو مشهور می‌کنیم و چرا.
ساخت حساب کاربری با نام و مشخصات جعلی در شبکه‌های اجتماعی و پیام‌رسان‌ها و ایجاد روابط دوستی با دیگران
شاید با خودتون بگید «عه این هم که مساله‌ای نداره، طرف نخواسته با هویت واقعیش فعال باشه». درست می‌فرمایید. این که هویت ساختگی داشته باشیم هم یک «حق» برای ماست (شاید جالب باشه بدونید که یکی از هجمه‌هایی که علیه فیسبوک هست همینه! که چرا کاربران رو فورس می‌کنه هویت واقعی خودشون رو بذارن روی اکانت‌هاشون) ولی نکات مهم‌تری هم وجود داره. در اینجا یک کیسی رو مثال میزنم.
فرض کنید شخصی هست که حساسیت گروه خاصی رو برانگیخته. شخص A و گروه G می‌گیم برای راحتی کار. حالا گروه G یک پلنی چیده که به شکلی، بخواد شخص A رو از مسیر خودش کنار بزنه. اینها میتونن یک «کارمند سابق» و یک «شرکت» باشن (خلاصه فکر نکنید همیشه ماجرا، ماجرای سیاسی و … است). پس گروه G چه می‌کنه؟ یکی رو مامور می‌کنه تا اکانتی بسازه و با اطرافیان A دوست شه. به این شکل میتونه طی دوستی با روش‌های مختلفی، اطلاعات به دست بیاره.
روش‌های کسب اطلاعات هم میتونن به خودی خود جالب باشن. در ادامه بعضیاشون رو لیست می‌کنم :
سوال در مورد توانایی‌های متفاوت شخص (در قالب تعریف و تمجید، تعجب، غیبت و …)
سوال در مورد تیپ شخصیتی فرد.
اعلام این که به شخص A علاقمند شده و نمی‌تونه پا پیش بذاره (بخصوص اگر A خانم باشه)
بدگویی از شخص برای سنجش نوع روابط و این که دیگران در مورد اون شخص چی میگن
دیدید، این فقط چهار حالتیه که به ذهن من می‌رسه. این حالات میتونه بسیار بسیار بیش از این قضیه باشه. فلذا حواستون باشه دفعه بعدی که پشت سر همکارتون حرف زدید، خدای نکرده به شخصی که باهاش خصومت داره دیتا ندید 😁
انتشار اخبار جعلی
اخبار جعلی هم میتونن در دامنه مهندسی اجتماعی قرار بگیرند! در واقع جمع کردن حجم خوبی از واکنش‌های مردم به خودی خود گرچه میتونه یک آزمایش باشه (که معمولا این آزمایش‌ها از قبل اطلاع داده میشن) اما به طور کل، برای پخش یک ایده خاص یا جمع کردن حجم خوبی از ری‌اکشن‌ها، استفاده میشه.
بخصوص در زمان‌هایی که به اتفاقات خاصی مثل انتخابات نزدیک هستیم، گستره این اخبار به شدت بزرگ میشه و خیلی راحت میتونن در نتایج بسیاری از تصمیمات جمعی تاثیرگذار باشن.
درخواست کمک‌های نقدی
در مورد این روش، بعدا به تفصیل خواهم نوشت. فقط حواستون باشه که خیلی از افرادی که در اینترنت به دنبال جمع‌آوری کمک‌های نقدی هستند، هدفشون «کار خیر» نیست. بلکه صرفا به جیب زدن حجم خوبی پوله 🙂
ساخت صفحات جعلی
در مورد این یکی هم، به زودی خواهم نوشت. فقط عبارت «ماحی گیری» یا Phishing رو در ذهنتون داشته باشید.
چطور از مهندسی اجتماعی در امان بمونیم؟
خب بذارید راحت بهتون بگم آدم فضول، آدم زاغ‌سیاه‌چوب‌زن، عین ویروس کروناست. نمیشه ازش در رفت، فقط میشه ریسکش رو کاهش داد. در ادامه، در مورد کاهش ریسکش کمی راهکار بهتون ارائه میدم 🙂
تا حد امکان سعی کنید داده‌های خودتون رو منتشر نکنید. اگر هم کردید، سعی کنید وسطش نویز بدید.
ارسال عکس و صدا برای غریبه‌ها کار خوبی نیست. سعی کنید کمتر سراغش برید.
به خیلی از موارد واکنشی نشون ندید. داغ شدن بعضی موارد (نمونه ساده‌ش دنگ کافه!) میتونه به سادگی باعث بشه که شما داده‌های زیادی از خودتون، محل زندگی و کارتون، روابطتون و … لو بدید.
از افرادی که به نظر ناامن میان دوری کنید!
به هرپیامی نیاز نیست پاسخ درست بدید.
برای واکنش دادن به اخبار و یا بازنشر اونها، منابع خبری معتبر داخلی و خارجی رو بررسی کنید. حساب‌های کاربری تاییدشده رو هم چک کنید و ببینید که کی، چی گفته. یافتن حقیقت به اون سادگی‌ها هم نیست چرا که بسیاری از موارد خبرهای کذب، توسط همون اشخاص نامدار هم میتونه نشر داده بشه.
در بحث‌هایی که حس می‌کنید ممکنه دردسرساز بشه براتون، شرکت نکنید.
از افرادی که مدعی هکری اجتماعی و مهندسی اجتماعی و … هستند دور شید. اینها ممکنه به خوبی بقیه هکرها نباشند، اما قطعا یه نقطه‌ای برای آزار شما پیدا می‌کنند.
در نهایت، آرزو دارم که هیچوقت طعمه گرگهای اینترنت نشید. این مطلب مطلب کاملی نیست و دست کم دو یا سه پست دیگه فقط در همین مورد خواهم نوشت. اما دوست دارم پیش از نگارش مطالب دیگر، نظرات شما رو پیرامون این موضوعات بدونم.
در پست قبلی، بررسی کردیم که اصلا MVC چیه و به چه کار میاد و یکم هم مثال ازش در روبی آن ریلز دیدیم. در این پست، قصد دارم مزایا و معایبش رو بگم و بگم که روبی آن ریلز، چه راه‌حلی برای مشکلاتش پیشنهاد می‌کنه.
باز هم لازمه که سلب ادعا کنم که این مطلب مطلقا آموزش روبی آن ریلز نیست و شما اگر میخواید روبی آن ریلز یاد بگیرید، میتونید تا پست بعدی منتظر باشید 😁
مروری بر کلیت MVC
از پست قبلی، این دید رو داریم که MVC در واقع یک روش تبدیل کردن موجودیت‌های محصول به یک سری مدل، کنترل ارتباطاتشون با هم و با دنیای بیرون با یک سری کنترلر و نمایششون به صورت ویوئه (متفاوت‌تر از قبلی شد، نه؟ چون صرفا بیانم رو در تعریفش عوض کردم). اما حرفی از مزایای و معایبش نزدم.
عمده‌ترین دلیلم برای ادامه ندادن، این بود که مطلب قبلی زمان زیادی از من گرفت و حتی مجبور به ریبوت کردن لپتاپم میانه راه شدم. خود مطلب هم شدیدا طولانی بود و مطمئن بودم از یک حدی طولانی‌تر می‌شد، دیگه کسی اون رو نمیخوند.
حالا که تعاریف رو با هم بررسی کردیم، بریم سراغ اصل مطلب 🙂
مزایا و معایب معماری MVC
مزایا
تسریع فرایند پیاده‌سازی : همونطوری که در پست قبلی دیدید، اکثریت قریب به اتفاق چارچوب‌های توسعه که با این معماری کار می‌کنند، ابزارهایی برای تولید و تست موجودیت‌ها در اختیار شما میذارن. این به خودی خود موجب تسریع فرایند پیاده‌سازی میشه. در مورد توسعه هم این قضیه میتونه تا حدی صادق باشه، البته توسعه رو در بخش معایب بررسی می‌کنیم.
تسهیل فرایند کار گروهی : در یک بیزنس، معمولا بیش از یک نیرو روی محصول نهایی – چه در پیاده‌سازی چه در توسعه – کار می‌کنه. این معماری به توسعه‌دهنده‌ها کمک می‌کنه بهتر بتونن محصول رو درک کنن. بخصوص اگر قرار باشه هر شخص روی یه بخشی کار کنه و پیاده‌ش کنه.
تسهیل فرایند به‌روزرسانی : طبیعیه که به‌روزرسانی یک محصول، کار ساده‌ای نیست. اما یک فرض ساده رو در نظر بگیرید. مثلا من، یک فروشگاه اینترنتی دارم، قراره در نسخه جدید وبسایتم، بخشی هم افتتاح کنم که افراد بتونن لوازم کارکرده هم خرید و فروش کنن. اضافه کردن یک موجودیت جدید به نرم‌افزاری که MVC نوشته شده به شدت ساده‌تر میشه و من فقط لازمه مدل بخش «کارکرده» رو اضافه کنم و روابطش با باقی اجزا رو پیاده‌سازی کنم.
تسهیل فرایند کشف و رفع باگ : خب از اونجایی که هر موجودیتی، در این معماری به شکلی جدا از موجودیت دیگره، خیلی راحت میشه فهمید مشکل از کجاست. البته لازمه این رو بگم که در معایب هم قراره به این بخش اشاره کنیم و در گوشتون هم میگم که Rest API در این زمینه میتونه بهتر عمل کنه 🙂
خب ما ایرانیا یک ضرب‌المثل معروف داریم که میگه «گل بی‌عیب، خداست». پس این معماری و طبیعتا فرمورک‌هایی که با این معماری کار می‌کنند هم خالی از ایراد نیستند. در این بخش از معایب MVC میگم و البته بخشیش هم از معایبی که برای ریلز و لاراول گفته شده نقل می‌کنم.
در مورد بخشی که از ریلز و لاراوله، اسمی از فرمورک نمیارم چون در نظرم این معایب، معایب معماری هستند و نه فرمورک. در واقع اینطوری فرض کنیم که یک سلولی که مشکلی داشته تقسیم شده و همه سلول‌های جدید، همون مشکل رو دارند 😁
معایب
سختی درک معماری : این موضوع، میتونه برای برنامه‌نویس‌های تازه‌کارتر، کمی مشکل‌ساز باشه. توصیه می‌کنم قبل از این که لقمه بزرگ بردارید و سراغ ریلز، جنگو یا لاراول برید حتما اول با سیناترا، فلاسک یا لومن کار کنید. به این شکل فرمورک‌ها میتونن براتون به شدت قابل درک‌تر بشن.
خارج شدن شکل نرم‌افزار از کنترل توسعه‌دهنده(ها) : این مورد کمی پیچیده‌ست. فقط بذارید به این شکل بهتون بگم که شما مثلا یه سری واژه رو نمی‌دونید چطور مدیریت کنید. مثلا ممکنه اسم مدل مربوط به حساب بانکی رو Hesab, Bank یا Bank Account بذارید و نفر بعدی که روی کد شما کار می‌کنه، با این قضیه به مشکل بخوره. بهترین راه اینه که این موارد، قبل از پیاده‌سازی کشف و مستند بشن.
انعطاف پایین : طبیعیه که وقتی یک جعبه‌ابزار کامل دم دستتون باشه، دیگه سراغ ساخت ابزار نمی‌رید. اکثر فرمورک‌های MVC هم این مشکل رو دارند و اگر شما بخواهید بخشی هم خودتون پیاده کنید، به شدت به مشکل می‌خورید.
پرفرمنس‌تایم پایین : خب از اونجایی که اکثر این فرمورک‌ها، دارن همه چیز رو خودشون هندل می‌کنن، ممکنه هزینه بالایی برای اجرا داشته باشند. البته این هزینه ممکنه با توجه به سخت‌افزارهای امروزی زیاد هم بالا حساب نشه، اما چرا وقتی میشه با کمترین هزینه کاری کرد، هزینه رو بی‌خود و بی‌جهت ببریم بالا؟
رفع اشکال پرهزینه : درسته که فرایند کشف و رفع باگ رو گفتیم که آسونه، اما هزینه بالایی داره. حواسمون باید به این موضوع باشه که داریم با چیزی کار می‌کنیم که همه چیش به همه چیش ربط داره و قطع این ارتباط میتونه هزینه زیادی وارد کنه بهمون.
بزرگ شدن غیرقابل کنترل پروژه : خب وقتی که MVC کار می‌کنیم، عموما خیلی کم پیش میاد که بخواهیم موجودیت‌ها رو به صورت سرویس‌های مجزا توسعه بدیم. در واقع اینجا خبری از میکروسرویس و اینا نیست! همین باعث میشه بیزنس از یک حدی که بزرگتر بشه، کنترلش به شدت سخت شه. از همین رو، معمولا در کنار MVC یک معماری دیگری مثل rest هم استفاده میشه که این داستان‌ها رو نداشته باشیم.
حالا بیاید ببینیم چه راه‌حلایی برای این قضیه داریم؟ یک راه خیلی خوب اینه که وقتی مدلی ساخته میشه، کنترلر و ویوهای مربوطه هم اتوماتیک تولید بشن. بعدها میتونیم اون چیزی که نیاز نداریم رو از این چرخه حذف کنیم. خب چطوری؟ در این بخش، دو راه حل میارم. یکی از ریلز و دیگری لاراول (فکر کنم کسی انتظار لاراول رو در این قسمت نداشت).
راه حل Ruby on Rails
در ریلز یک مفهومی داریم به اسم scaffold. این مفهوم چی کار می‌کنه؟ میاد مدل، ویو و کنترلر یه موجودیت رو برای ما میسازه. برای زمان‌هایی که Rest API نداریم و میخواهیم صفر تا صد اپ رو خودمون بزنیم، یکی از بهترین انتخاب‌ها در ساخت و طراحی موجودیت‌ها همینه.
مثال پست بلاگ رو در نظر بگیرید. چطوری میتونیم به سادگی همه‌چیش رو هندل کنیم؟! ساده‌ست، کافیه این دستور رو تایپ کنیم:
rails generate scaffold Post title:string slug:string body:text
و این دستور به خودی خودش میاد و همه چیزهایی که نیاز داشتیم رو میسازه. خوبی‌های این روش چیه؟
استاندارد بودن متدها در کنترلر (یعنی نیاز نیست دیگه زحمت مضاعف برای Routing بکشیم)
وجود viewهایی که پارامترهای درست ارسال و یا دریافت می‌کنن (کاهش هزینه کشف و رفع باگ در مراحل اولیه توسعه)
اما خب یک بدی بزرگ هم داره و اون اینه که خلاقیت شما رو میتونه کلا نابود کنه. برای اون هم راهکارهایی هست. مثل این که شما یه کنترلر مجزا بسازید و متدها و endpointهای مورد نظر خودتون رو اونجا تعریف کنید.
باقی موارد، همه مثل مطلب قبلیه و خب در مطالبی که در آینده نزدیک خواهم نوشت، حتما اشاره خواهم کرد به این موضوع که چه فعل و انفعالاتی در ریلز رخ میده برای ساخت این ماجراها 🙂
راه‌حل در لاراول
یک سلب ادعای کوچک ابتدای این بخش بکنم؟ عمده تجربه من با لاراول روی Rest API بوده و فرصتی نشده که MVC باهاش کار کنم. شاید هم هیچوقت MVC کار نکنم. اما این راه‌حل قطع به یقین برای MVC هم پاسخگوئه.
اول از همه یک مدل می‌سازیم:
php artisan make:model Post
و خب وارد جزییات نمی‌شم، میتونیم جزییات مدل رو در فایلهای مربوطه بررسی کنیم.
بعد برای این مدل به این شکل میتونیم کنترلر بسازیم:
البته لازم به ذکره که باید دقت داشته باشید همیشه کنترلرها از جنس resource و CRUD نیستن و این دو راهکار، در واقع برای وقتی خوبن که شما نیازمند CRUD باشید و نخواهید هزینه ساخت کنترلر «از بیخ» رو متحمل بشید.
جمع‌بندی مطالب
در دو مطلب، هم تعاریف مرتبط با MVC رو یاد گرفتیم، هم یه نیم‌چه اپ MVC نوشتیم و هم مزایا و معایبش و راه‌حل‌های احتمالی برای معایب قضیه رو بررسی کردیم.
این مطالب، بیش از این که رنگ و بوی برنامه‌نویسی داشته باشند، مرتبط با مهندسی نرم‌افزار بودند و خوشحالم که در این زمینه هم محتوایی تولید کردم. فکر کنم این پست دیگه جمع‌بندی خاصی نیاز نداشته باشه. فقط خواستم بابت وقتی که برای خوندن این مطلب گذاشتید، ازتون تشکر کنم 🙂
در دنیای امروزی، بخش بسیار بزرگی از بیزنس و همچنین توسعه نرم‌افزار مرتبط به توسعه عملیات (Dev Ops)، مدیریت سیستم (System Administration) و همچنین استقرار و یکپارچگی ادامه‌دار (CI/CD) میشه. شاید حتی مهم‌تر از اصل نرم‌افزار، رسیدگی به این موضوعات باشه. در این پست، قراره که با هم بررسی کنیم چطور میتونیم در پایان روز، به خودمون بگیم DevOps Engineer؟ و چه چیزایی باید بلد باشیم؟ 🙂
مدیریت سیستم یاد بگیرید
یادگیری مدیریت سیستم، بخش «عملیات» قضیه رو معمولا شامل میشه. پس لازمه که اینجا چیزایی رو بلد باشیم که معمولا در شرکت‌ها و سازمان‌های بزرگ بهشون نیاز میشه. اما قبل از اون، لازمه که یه چیزایی رو به صورت عمومی بلد باشیم. پس بیاید با هم بررسی کنیم که عمومیات دواپس شدن چیا هستن؟
یادگیری لینوکس. عموم شرکت‌ها در دنیا در حال حاضر، سرورهای لینوکسی دارند. بلد بودن لینوکس، یک «باید» در یادگیری دواپس محسوب میشه. یادگیری لینوکس اصلا سخت نیست. کافیه یک توزیع خاص (مثل اوبونتو) رو نصب کنید و باهاش بازی کنید. کم کم دستتون میاد که چی به چیه. بعد از این ماجرا، میتونید یک سرور اجاره کنید و چیزایی که یاد گرفتید رو روش تست کنید.
آشنایی با وب‌سرورها. وب‌سرورها، نرم‌افزارهایی هستند که به شما امکان نمایش نرم‌افزار و محتوای تولیدی از طریق پروتکل HTTP رو میدن. در دنیای امروز اکثریت قریب به اتفاق کسب و کارهای کوچک و حتی بزرگ، از NGINX استفاده می‌کنن. پس بد نیست بعد از این که لینوکس یاد گرفتید، روی سرور یا ماشین مجازی لینوکسیتون یک وب‌سرور نصب کنید و سعی کنید یک صفحه استاتیک باهاش نمایش بدید.
آشنایی با شبکه. گرچه معمولا این مورد رو باید اول از همه بیاریم، اما من شخصا معتقدم که یادگیری لینوکس در بحث مدیریت سیستم به هرچیزی ارجحه. اما از این موضوع که بگذریم، چرا شبکه؟ شبکه پایه و اساس دواپسه. شما بدون بلد بودن شبکه، تقریبا هیچ کاری نمی‌تونید بکنید. اما چه حد شبکه بلد بودن خوبه؟ دقت کنید که اینجا قرار نیست ما نیروی آی‌تی یک سازمان باشیم، پس فقط کافیه که پایه‌های شبکه، آی‌پی و بعضی پروتکل‌های مرسوم (SSH, FTP, HTTP, SMTP و …) رو بدونیم و بدونیم که هرکدوم چطور و کجا کار می‌کنند.
آشنایی با فایروال و تامین امنیت شبکه. فکر کنم عنوان خودش گویاست. در لینوکس، ما معمولا از iptables یا اینترفیس‌هایی که براش ساخته میشن (مثلا اوبونتو UFW و دبیان apparmor رو دارند) استفاده می‌کنیم. این خیلی مهمه که شما بعنوان مدیر سیستم، در جریان باشید که چه چیزایی از بیرون در دسترسه و این حجم از دسترسی، چقدر میتونه آسیب‌زا باشه.
موارد بالا، مواردی هستند که حتما باید بلد باشید. فرقی هم نمی‌کنه که جایی استخدام شدید یا اگر قراره بشید، ازتون خواستند بلد باشید یا نه. در واقع «باید»های مدیریت سیستم موارد بالان.
اما در بسیاری از شرکت‌ها یک سری سناریو خاص وجود داره که اینها رو میتونیم با هم بررسی کنیم، گرچه قرار نیست همه موارد رو با هم یاد بگیریم، اما چیزایی که به نظرم ممکنه وجود داشته باشند رو در اینجا بررسی می‌کنم.
استفاده از یک ابر خصوصی به جای چندین سرور عمومی. این مورد، مورد خوب و امنیه. گذشته از این که باعث میشه خیلی از موارد (مثل دیتابیس و …) از بیرون در دسترس عموم قرار نگیرند، هزینه‌ها رو هم پایین میاره. فقط حواستون باشه که در این مورد، معمولا چند چیز اتفاق می‌افته که باید بلد باشید:
استفاده از لود بالانسر : لود بالانسرهای مرسوم مثل haproxy میتونن نقطه شروع خوبی باشن. البته این هم در نظر داشته باشید که معمولا ارائه‌دهندگان سرویس‌های ابری؛ خودشون هم لود بالانسینگ رو انجام میدن.
استفاده از سیستم‌های مانیتورینگ : طبیعتا شما برای این که ببینید هرکجا چه اتفاقاتی می‌افته، نیاز به یک سیستم مانیتورینگ خوب دارید. در حال حاضر سرویس‌هایی مثل prometheus و zabbix وجود دارند. همچنین میتونید اینها رو به grafana و امثالهم متصل کنید و به شکل زیبایی، اونها رو ویژوالایز کنید.
استفاده از نرم‌افزارهای بیلد شده به صورت سفارشی. گرچه این مورد رو شخصا درک نمی‌کنم (چون نسبت به نرم‌افزاری که از کانال رسمی – مثل مخزن‌های توزیع لینوکستون – نصب می‌کنید ممکنه امنیت و پایداری کمتری نشون بدن) اما برخی سازمان‌ها ممکنه وب‌سرور، کامپایلر یا مفسر یا حتی کرنل رو خودشون از نو بیلد کرده باشن. پس یادتون باشه این مورد هم تا حدی یاد بگیرید که اگر نیاز به بیلد مجدد شد گیر نکنید 😁
در مورد مدیریت سیستم به قدر کافی یاد گرفتیم، دیگه چی می‌مونه؟ نظر من رو بخواید الان وقتشه که یک سری ابزار رو با هم بررسی کنیم. توجه کنید که ابزارهایی که در این بخش ازشون حرف میزنم، ابزارهایی هستند که خودم باهاشون تجربه کار دارم. فلذا اگر ابزاری از قلم افتاده، در بخش نظرات در مورد ابزارهای مورد نظر خودتون صحبت کنید. من خوشحال میشم 🙂
ابزارهایی که باید یاد بگیرید
وب‌سرور
گرچه این رو در بخش قبلی اشاره کردم، در اینجا میخوام صرفا کمی در مورد NGINX حرف بزنم. یادتون باشه که NGINX امروزه یک انتخاب خوبه چون:
در بسیاری از توزیع‌ها، وجود داره. در حدی که خیلی از توزیع‌های سروری رو وقتی نصب کنید؛ ممکنه همراهش نصب شده باشه.
پیکربندی به شدت ساده‌ای داره (و خب کاش حداقل نیاز نبود ته هر خط پیکربندی شما یک سمی‌کالن بذاری)
ابزارهای جانبی بسیار خوبی مثل python3-certbot-nginx براش ساخته شده که امکان SSL و … گرفتن برای دامنه خاص و زیردامنه‌ها و … رو به شدت ساده می‌کنه.
تقریبا برای هرکاری یه آموزشی ازش هست!
ابزارهای CI/CD
خب ابزارهای CI/CD چی هستند؟ به صورت کلی، این ابزارها اینجان که کار استقرار (Deploy) و یکپارچگی (Integration) هرآپدیت با نسخه قبلی رو اتوماتیک انجام میدن. ابزارهای زیادی برای این کار وجود دارند من جمله Travis CI, Jenkins و البته معروف‌ترینشون Gitlab CI/CD (حداقل در ایران).
این ابزارها به این شکل عمل می‌کنن که یه سری فایل پیکربندی (در مورد گیت‌لب از نوع YML ) دریافت می‌کنند و اون رو بررسی می‌کنند. سپس مطابق اون، عملیات رو انجام میدند و نرم‌افزار شما رو مستقر می‌کنن. خوبی گیت‌لب در این زمینه اینه که به ازای هر به‌روز‌رسانی‌ای که شما انجام بدید، یک بار Pipeline اجرا می‌کنه و بروزرسانی‌ها رو روی سرور مورد نظر اعمال می‌کنه. البته باقی ابزارها هم امکان اتصال به گیت رو دارند پس نگران نباشید.
ابزارهای مانیتورینگ
طبیعتا بالا بودن یا نبودن سرویس‌ها، دیتابیس، سرویس‌هایی که از بیرون دریافت می‌کنیم و یکپارچگی داریم باهاشون، مهمن. همینطور ظرفیتی که در دیسک و حافظه و … اشغال شده هم مهمه که دونسته بشه. فلذا اینجا لازمه که ابزاری باشه که اینجا بیاد و این رو برای ما چک کنه.
این ابزار معمولا چیه؟ خب ابزارهای زیادی براش هست و من تجربه‌م استفاده از prometheus بوده. پرومتئوس یک سری ابزار خاص داره که بهش میگن exporter. شما روی هر قسمتی که نیاز دارید (مثلا nginx یا خود سرور که بهش میگن node یا هرچیزی از این قبیل) یک اکسپورتر نصب کنید و نتایج آنالیزها رو اینجا ببینید.
همچنین نتایج معمولا روی پرمتئوس زیبا نیستن، به همین خاطر شما میتونید یک ابزار بهتر مثل Grafana نصب کنید و نتیجه رو به شکل قشنگی visualize کنید. همچنین میتونید روی هرکدوم یک سیستم alerting ست کنید که از روش‌های مختلفی مثل پیامک، ایمیل یا حتی پیام در اسلک بهتون هشدار بده که کجا چی درست نیست.
ابزارهای ذخیره‌سازی
خب، این هم یه چیزی که شاید کمتر ازش با خبر بوده باشید :). در دنیای امروز تقریبا کسی نیست که رو همون سروری که نرم‌افزارش هست، فایل ذخیره کنه. پس چی کار می‌کنن؟ هیچی، اونجاهایی که جزء دنیا حساب میشن؛ معمولا از Amazon AWS استفاده می‌کنن و پارتیشن S3 دریافت می‌کنن. S3 یعنی Simple Storage Solution (سه تا S) و خب این حقیقت وجود داره که راهکار بهتریه. چرا؟ چون شما برای ذخیره‌سازی صرفا هارد نیاز داری و نه پردازنده یا رم زیاد.
اما نگران نباشید، اگر به هر دلیلی دسترسی به AWS ندارید، میتونید در همین ایران از ابزارهایی مثل ابرآروان و پشتیبان هم استفاده کنید. فقط کافیه که یاد بگیرید که چطور نرم‌افزار رو با S3 یکپارچه کنید (اینجا اهمیت این ماجرا که مهندس دواپس نیازمند اینه که دانش برنامه‌نویسی داشته باشه مشخص میشه) و دستورالعمل‌های لازم رو به توسعه‌دهنده‌ها بدید؛ یا این که اصلا خودتون کدبیس رو درک کنید و این یکپارچه‌سازی رو انجام بدید.
یک راه دیگه هم داشتن سرور با حجم بالای هارددیسک (در ابعاد ترابایت) میتونه باشه. بعد از اون شما نیاز دارید تا یک نمونه S3 روی اون مستقر کنید. برای این کار میتونید از ابزاری مثل minio بهره بگیرید.
ابزارهای ارکستراسیون
ابزارهای ارکستراسیون چی هستند؟ ارکستر در موسیقی، به معنای «گروهی از نوازندگان»ــه. یعنی یک گروهی که مثلا دو نفر ویولن میزنن، یک نفر ویولا و یک نفر چلو. در دواپس ارکستر به مجموعه‌ای از سرورها یا شبکه‌ها گفته میشه که یک کار انجام میدن. تا حالا دقت کردید چطوریه که شما سرعت کارتون با توییتر در آلمان با سرعت کارتون با توییتر در آمریکا یکیه؟ یا مثلا چطوریه که شما از ایران یک عکس رو پست می‌کنید و مثلا خاله شما در آمریکای شمالی اون رو لایک می‌کنه؟!
علتش اینه که این نرم‌افزارها به عبارتی Orchestrate میشن (فارغ از بحث CDN و …) یعنی از یک نرم‌افزار و همچنین دیتابیسشون (البته دیتابیس Cache و نه دیتابیس‌های اصلی) بیش از یک نمونه در حال اجراست. برای شما سوال نشده که اینا چطور هندل میشن؟ خب جواب اینه که ابزارهای ارکستراسیون استفاده میشه.
از بین این ابزارها میشه به Docker Swarm و Kubernetes و Ansible اشاره کرد. طبق تجربه با Ansible به شما بگم که شما تنظیماتی که نیاز دارید رو مشابه CI/CD در یک سری فایل پیکربندی (انسیبل بهشون میگه استوری) می‌نویسید و مجموعه‌ای از استوری‌ها رو در یک namespace قرار می‌دید. مثلا فرض کنید همین وبلاگ کجاها قراره باشه، من یه namespace به اسم haghiri75 میسازم و اطلاعات استقرار رو بهش میدم.
با ابزارهای ارکستراسیون، آماده‌سازی و پیاده‌سازی سناریوهای سرور و یا ابر خصوصی به شدت ساده‌تر و سریع‌تر خواهد شد.
بسیار عالی، این بخش هم تمام شد. یک بخش کوچک هم مونده که اون هم میخونیم و بعدش این دفتر هم به پایان می‌رسونم. تا اینجا اگر خوندید، یکم به خودتون استراحت بدید. بعد بخش بعدی رو بخونید و یادتون نره که این مطلب رو با دوستانتون به اشتراک بذارید.
برنامه‌نویسی یاد بگیرید
بسیار خوب، در این بخش که در واقع بخش پایانی این مطلب در مورد اینه که چطور DevOps بشیم، لازمه اشاره کنم به این که نیاز دارید برنامه‌نویسی بلد باشید. حالا به چه زبونی و در چه حد؟ اینها مهمن. خب در این قسمت یکم در مورد زبان‌هایی که «باید» بلد باشید صحبت می‌کنم و بعد از اون هم راهنمایی میدم در مورد زبان‌هایی که احتمالا در جریان کار مجبورید باهاشون کار کنید.
پایتون، از چیزایی که باید بلد باشید!
چرا پایتون؟ خب پایتون این روزها طوریه که شما حتی مهندس کامپیوتر یا توسعه‌دهنده هم نباشی احتمالا دوست داری یادش بگیری و خیلی‌ها کم و بیش پایتون رو بلدند. اما چرا بعنوان یک مهندس دواپس باید پایتون بلد باشیم؟
بر خلاف گذشته که خیلی از پیکربندی‌های سرور با پرل انجام می‌شد، سالهاست که توزیع‌های مطرح لینوکس مثل اوبونتو، ردهت، دبیان، سنت‌اواس و … دارند میرن سمت پایتون. پس به نوعی شما زبانی رو یاد گرفتید که برای پیکربندی سرور داره استفاده میشه و عملا ضرری نکردید.
ابزارهای مانیتورینگ و همچنین پنلهایی که براشون ساخته شده هم معمولا پایتونی هستند. حداقل گرافانا که با پایتون نوشته شده و دونستن پایتون میتونه در بهبود کارکرد این قضیه به شما کمک بده.
احتمال خوبی هم وجود داره که نرم‌افزاری که میدن به شما تا مستقر کنید هم پایتونی باشه، فلذا پیاده‌سازی بخش دواپسی قضیه هم میتونه براتون ساده‌تر باشه.
و در نهایت؛ شما ممکنه ابزاری نیاز داشته باشید که موجود نباشه. پس خودتون باید پیاده‌ش کنید. با پایتون این قضیه به شدت سریع اتفاق می‌افته.
یک زبان سیستمی
زبانهای سیستمی، زبانهای برنامه‌نویسی هستند که برای توسعه ابزارهای سیستم‌عامل استفاده میشن، برای تعامل با سخت‌افزار پرفرمنس بهتری دارند و در نهایت برای ایجاد ابزارهای زیرساختی مناسب‌ترند. اینجا نمیخوام شما رو به یادگیری اسمبلی تشویق کنم، بلکه ازتون خواهش می‌کنم همیشه نیم‌نگاهی به زبان‌هایی مثل Rust یا Go داشته باشید (و در نظر بگیرید که Go حتی در بکند هم استفاده میشه فلذا یادگیریش خالی از لطف نیست!).
زبانی که سازمان ازش استفاده می‌کنه
این هم نیاز به گفتن نداره. شما نیاز دارید تا کدبیس رو یاد بگیرید و درکش کنید. حداقل وقتی که قراره دواپسی‌جات رو روی کد اعمال کنید این مهم خودش رو نشون میده. نگران هم نباشید، معمولا DevOps درگیری به شدت کمتری با کدبیس مستقیم درگیر میشه. پس اگر حس و حال کار تو تیم توسعه‌دهنده‌ها رو ندارید نگران این مورد هم نباشید :))
خب این دفتر هم به پایان رسوندم. جا داره در انتها، یک نکته خیلی مهم رو عارض بشم خدمت شما. سعی من کلا بر این بود که مطلبم خیلی مرتبط به یک دوران خاص از تاریخ نباشه و مثلا ۳ سال بعد هم قابل استفاده باشه. همچنین، این رو یادتون باشه که این مطالبی که در اینترنت موجودند، معمولا تجربیات شخصی هستند.
شخصا معتقدم تجربیات ارزشمندن، اما یه نکته مهم اینه که تجربه‌ها یکسان نیستند. مثل همین مطلب، مطلبیه که من طی تجربه خودم بهش رسیدم و ممکنه شما مسیر متفاوتی رو در سفرتون به دنیای دواپس طی کرده باشید. به همین خاطر هم کل مطلب رو در یک جمله خلاصه می‌کنم که «فرمول کلی برای دواپس شدن وجود نداره».
امیدوارم مطلب مفیدی بوده باشه، در نهایت هم سال نوتون پیشاپیش مبارک 🙂
وبلاگ شخصی محمدرضا حقیری، برنامه‌نویس، گیک و یک شخص خوشحال
