بایگانی برچسب: s

چگونه در ده دقیقه، یک فراجستجوگر بسازیم؟

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

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

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

آشنایی با searx

خب searx یک نرم‌افزار آزاده که هدفش، بهبود تجربه جست و جوی افراد در اینترنته. این نرم‌افزار، به دو صورت قابل دسترسیه. اول این که تعدادی نمونه عمومی داره (لینک نمونه‌های عمومی در اینجا قرار گرفته) و هم به صورت «خودمیزبان» یا همون self-hosted. متد خودمیزبان یعنی شما به عنوان کاربر، می‌تونید به صورت رایگان یا با پرداخت پول (بسته به مدل کسب و کار و توسعه اون پروژه خاص)، اون نرم‌افزار رو روی هاست یا سرور مورد نظر خودتون نصب کنید.

در این آموزش، قراره با کمک یک سرور لینوکسی، یک زیردامنه، یک کارساز وب و داکر؛ یک فراجستجوگر ساده رو به کمک هم بیاریم بالا. به این شکل می‌تونیم هم یک نمونه عمومی عرضه کنیم، هم این که دیتای کمتری در اختیار شرکت‌هایی مثل گوگل یا مایکروسافت بذاریم.

ساخت فراجستجوگر

برای ساخت فراجستجوگر خودمون، نیاز به موارد زیر داریم:

  • سرور لینوکسی. من شخصا از اوبونتو ۱۸.۰۴ استفاده کردم. برای پردازش بهتر نتایج و نخوردن به مشکل تحریم و …؛ بهتره که سرور داخل ایران هم نباشه. به همین خاطر، من از سرور هلند استفاده کردم (کشور محل قرارگیری سرور، کاملا به خودتون بستگی داره).
  • یک دامنه یا زیردامنه. برای این پروژه من از searx[dot]haghiri75[dot]com استفاده کردم.
  • کمی آشنایی به کارهای سروری. اگر آشنایی خاصی ندارید هم مهم نیست! در حد لزوم در این مطلب یاد می‌گیرید 😁

آماده‌سازی سرور

وقتی سرور رو از ارائه‌دهنده سرور تحویل گرفتیم (با فرض اوبونتو/دبیان بودنش) نیازه تا اول لیست بسته‌های اون رو کمی به روز کنیم:

sudo apt update

و اگر لازم شد، کل سیستم‌عامل هم یک بار به‌روز می‌کنیم:

sudo apt full-upgrade

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

sudo apt install nginx python3-certbot-nginx docker.io

خب ببینیم این بسته‌ها برای چین؟

  • nginx: این بسته، وب‌سرور یا همون کارساز وب ماست. چیزی که باعث میشه ما بتونیم بدون مشکل، یک وبسایت یا نرم‌افزار تحت وب رو استفاده کنیم.
  • python3-certbot-nginx: از این بسته استفاده خواهیم کرد تا یک گواهی SSL برای وبسایت خودمون بگیریم.
  • docker.io: داکر یک سیستم کانتینرییزشنه. در واقع نرم‌افزارها رو داخل بسته‌های کوچولو قرار می‌ده و همه ملزوماتشون اونجاست. فقط تنها موردی که داره، اینه که از هسته سیستم عامل استفاده می‌کنه برای مدیریت فرایندها (در واقع تفاوتش با ماشین مجازی همینه).

حالا ما سرور رو آماده کردیم. گام بعدی چیه؟

آماده‌سازی دامنه

برای آماده‌سازی دامنه، کافیه که یک رکورد A با IP سرور مورد نظر ایجاد کنید. البته در بعضی موارد از CNAME هم میشه استفاده کرد اما اینجا چون سرور از وبسایت جدا بود، یک A تعریف شد. بعد از این که رکورد رو تعریف کردیم، باید ۵ تا ۱۰ دقیقه صبر کنیم تا عموم DNS Server های اینترنت، بشناسنمون. بعدش می‌تونیم به کارمون ادامه بدیم.

حالا ۱۰ دقیقه گذشت و یک قهوه هم خوردیم و آماده‌ایم که مرحله بعدی رو انجام بدیم.

دریافت گواهی SSL

خب دریافت گواهی SSL هم بسیار ساده‌ست. کافیه این دستور رو در سرور اجرا کنید (و دامنه من رو با دامنه خودتون عوض کنید):

sudo certbot -d searx.haghiri75.com --nginx

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

راه‌اندازی داکر و نصب فراجستجوگر

خب اول از همه کاربر خودمون (که در اینجا فرض می‌گیریم نام کاربریش هم Ubuntu ئه) رو به گروه داکر اضافه می‌کنیم:

sudo usermod -aG docker ubuntu

بعدش کافیه یک بار از نشست SSH خارج شیم و دوباره به سرور SSH بزنیم. دقت داشته باشید که این بخش الزامی نیست؛ ولی اگر شما این کار رو نکنید بعدا در استفاده از داکر، نیازمند دسترسی ریشه خواهید بود. نگران دسترسی ریشه هم نباشید چون با sudo قابل حله.

بعد از این مورد، ایمیج searx رو از رجیستری داکر دریافت می‌کنیم:

docker pull searx/searx

خب در حال حاضر، اتفاق خاصی می‌افته؟ خیر. فقط تصویری که searx روی اون نصب شده، روی سرور ما دانلود شده.

بعد از اون، نیازداریم که یک کانتینر براش بسازیم. برای این، مراحل زیر رو طی می‌کنیم:

mkdir searx
cd searx
docker run --rm -d -v ${PWD}/searx:/etc/searx -p 8080:8080 -e BASE_URL=http://localhost:8080/ searx/searx

خب تبریک به شما، الان شما یک فراجستجوگر دارید.

اما صبر کنید! هنوز نمی‌تونیم بهش دسترسی پیدا کنیم. پس چه کنیم؟

پراکسی معکوس برای دسترسی به محتوا

خب اینجا نیاز داریم که از پراکسی معکوس استفاده کنیم. انجینکس علاوه بر این که وب‌سروره، پراکسی معکوس هم هست و خیلی از ما عمدتا از قابلیت پراکسی معکوسش برای اجرای نرم‌افزارهای تحت وبمون استفاده می‌کنیم. مثل همین آموزش دپلوی کردن یک پروژه ریلز نوشته بودم (لینک). دونستن این که پراکسی معکوس چیه و چی کار می‌کنه، از ملزومات پایه‌ای مدیریت سیستم و همچنین دواپس و CI/CD محسوب میشه (جهت اطلاعات بیشتر این پست رو بخونید).

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

sudo nano /etc/nginx/sites-enabled/default

و سپس دنبال دامینمون بگردیم (در نانو با ctrl + W میشه). بعد از این که دامینمون رو پیدا کردیم کافیه بخش location / رو پیدا کنیم (معمولا دو سه خط پایین‌تر از دامین و تنظیماتشه) و سپس به این شکل درش بیاریم:

location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                # try_files $uri $uri/ =404;
                proxy_pass http://localhost:8080;
        }

و بعدش هم کافیه که دستور زیر رو اجرا کنیم تا انجینکس ریستارت بشه:

sudo systemctl restart nginx

استفاده از فراجستجوگر شخصی

سخن آخر

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

موضوع بعدی اینه که فراجستجوگرها، علاوه بر این که می‌تونن در حفظ حریم شخصی و … موثر باشند، می‌تونن کاملا بیزنسی هم کار کنند. مثلا هرکلید واژه‌ای که سرچ کنید رو صرفا در موضوع خاصی دنبالش بگردند. مثلا شما اگر سرچ کنید «سیب‌زمینی» فقط در وبسایت‌هایی که وبینار میزبانی می‌کنند دنبالش بگرده. وقتی سرچ می‌کنید «قشم» فقط در وبسایت‌های گردشگری دنبالش بگرده و الی آخر.

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



Share

داستان برنامه‌نویس شدن من – قسمت دوم

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

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

ورود به دانشگاه

در طی این سالها، یعنی از حدود ۹۱ تا ۹۳ راه‌های زیادی رو رفتم که سرویس‌ها و نرم‌افزارهای خاصی رو طراحی کنم و خب دروغ چرا، تا حد زیادی هم رویای استیو جابز یا زاکربرگ شدن هم در سر داشتم و خب کارهای مختلفی مثل ایجاد انجمن‌های اینترنتی مختلف (ایران‌بی‌اس‌دی، ایران‌هکینتاش و …) گرفته تا برپا کردن شبکه‌های اجتماعی و نرم‌افزارهای آنلاین دیگر (اکسوال، نکست‌کلود و …) رو انجام می‌دادم. راستش این راه‌ها من رو به قول خارجی‌ها Satisfy نمی‌کرد و همچنان دنبال این بودم که یک سیستم عامل خوب بسازم!

خلاصه شد سال ۹۲ و ما از شهر بندرعباس به تهران برگشتیم. اون سال، سال پیش‌دانشگاهی من بود (و بد نیست این داستانکم رو هم پیرامونش بخونید) و اون سال، یک تصمیم بزرگ هم گرفتم. تصمیمم این شد که جبیر به جای این که مبتنی بر اوبونتو (یک توزیع از گنو/لینوکس)، یک نسخه شخصی‌سازی‌شده از FreeBSD باشه. از همین رو، شروع کردم به رفتن به IRC های مختلف، سوال پرسیدن و مستندات خوندن. بعد از چندین ماه مطالعه، وضعیت اینترنت خونه و خودم تا حد خوبی پایدار شد و بعد شروع کردم به انجام تغییرات روی کد FreeBSD.

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

داستان برنامه‌نویس شدن من - محمدرضا حقیریشرکت در لاگ‌ها و رویدادها و آخر و عاقبت پروژه جبیر

حضور در تهران و دانشجو شدن، به من کمک کرد که وارد جامعه بشم و در رویدادهای نرم‌افزار آزاد و متن‌باز و سایر رویدادها (مثل PyCon و …) شرکت کنم. اولین رویدادی که شرکت کردم، رویدادی بود به اسم «جامعه رایانش ابری آزاد». در اون رویداد با KVM و Docker آشنا شدم و تا حد زیادی هم دانشم در زمینه Containerها و مجازی‌سازی تا حد خوبی بالا رفت.

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

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

داستان برنامه‌نویس شدن من - محمدرضا حقیری

یادگیری روبی، ورود به حوزه سخت‌افزار و دیگر هیچ!

مهرماه ۹۳ بود که من خیلی جدی تصمیم گرفتم حداقل یک زبان برای توسعه وب رو جدی یاد بگیرم. قبل‌ترش، کتاب «از این پس پایتون» رو خونده بودم و به همین خاطر هم کمی با پایتون و فلسک آشنا بودم. دوستی یک کتاب جنگو هم برای من ارسال کرد. اما در همون هنگام در بحثی در IRC که دقیق یادم نیست مربوط به occc بود یا لاگ کرج، دوستی به من پیشنهاد کرد که روبی و روبی‌آن‌ریلز رو یاد بگیرم. در ادامه‌ش، توصیه کرد که حتما با دیتابیس‌ها آشنا شم و کمی هم مهندسی نرم‌افزار یاد بگیرم.

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

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

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

خلاصه این مورد هم گذشت و رسیدیم به شهریور ۹۶. یعنی جایی که من خیلی جدی و رسمی وارد بازار کار شدم.

داستان برنامه‌نویس شدن من - محمدرضا حقیری

ورود به بازار کار

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

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

سخن آخر

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

موفق باشید 🙂

 

Share

داستان برنامه‌نویس شدن من – قسمت اول

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

من کی هستم؟

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

فکر کنم پس از حدود ۱۰ سال حضور مداوم در جامعه‌های مختلفی مثل نرم‌افزار آزاد، جامعه فارسی‌زبان اوبونتو، جامعه Open Street Map (که البته در این آخری حضورم خیلی کم‌رنگ‌تر بود) و جامعه بینایی ماشین (لینک) دیگه الان بدونید که شخص «محمدرضا حقیری» یک برنامه‌نویسه که دستی بر لینوکس، BSD، پایتون، کمی سخت‌افزار داره و تبحر خاصی هم در تپه نوردی!

اگر دوست دارید بیشتر از من بدونید، در روزی که این پست نوشته شده (یعنی ۱۱ مهر ۱۴۰۰ هجری خورشیدی)، من چندین ماه از بیست و ششمین سال زندگیم می‌گذشته و در حال کار روی یکی از پروژه‌های خیلی جدی بودم و این پست رو برای این نوشتم که این داستان رو با شما به اشتراک بذارم. خب، من رو شناختید؟ بیایید بریم سراغ داستان برنامه‌نویس شدنم.

داستان برنامه‌نویس شدن من - محمدرضا حقیری

شروع برنامه‌نویسی

ما یک سری کتاب برنامه‌نویسی ویژوال بیسیک ۶ (لینک) در کتابخونه داشتیم. فکر کنم اواسط یا اواخر سال ۸۶ بود که من شروع کردم به خوندن یکی از این کتابا. برام خیلی جالب بود که چطور اینقدر این زبان هلوئه 🙂 از اون جالب‌تر این که اون زمان Windows Form هم چیزی بود که خیلی رو بورس بود و خیلی از برنامه‌نویس‌ها ازش استفاده می‌کردند. یادمه که همون دوران، شرکت «پرند» هم یک مجموعه به اسم «کینگ» داشت (و البته فکر کنم هنوز هم داره) که درونش هزاران نرم‌افزار وجود داشت.

در یکی از دیسک‌های کینگ، یک کتگوری Programming بود که ذیل اون، ویژوال استودیو قرار داشت. یادمه که با استفاده از دیسک مربوطه، ویژوال استودیو رو نصب کردم و شروع کردم به پیاده کردن چیزایی که در اون کتاب نوشته بود. یک فرم ساختم و یک لیبل زدم و روی لیبل نوشتم Hello World و شاید ندونید؛ ولی اون لحظه حسی که داشتم با حس آرمسترانگ وقتی رسیده بود روی ماه برابری می‌کرد. خلاصه که بعد از این که دورهای افتخار رو زدم، نشستم به خوندن باقی کتاب. اما می‌دونید چی شد؟ کتاب با VB6 آموزش می‌داد و فکر کنم من ویژوال‌ استودیو ۲۰۰۵ و چنین چیزی رو داشتم.

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

خلاصه که سال تحصیلی بعدیش، من تا حد خوبی روی مهارت‌های توسعه‌دهندگیم کار کردم. البته خیلی از ابزارهایی مثل Multi Media Builder که استفاده می‌کردم، ابزار برنامه‌نویسی محسوب نمی‌شدند، اما خب بهرحال برای این که در جشنواره‌های دانش‌آموزی و … شرکت کنم، بد نبودن. خلاصه که گذشت و گذشت و گذشت و رسیدیم به سال سوم راهنمایی. سوم راهنمایی من، سال جنجالی ۸۸ بود. سالی که تا حد زیادی افراد برای آینده خودشون، نگران شده بودند و طبیعتا من و خانواده من هم از این قاعده مستثناء نبودیم.

در این سال، یه جو قشنگی روی مدرسه حاکم شده بود. به طرز عجیبی مدرسه ما، دوست داشت که قطب تولید نرم‌افزار دانش‌آموزی باشه، قطب رباتیک منطقه خودش باشه و … . حقیقتا من این فرصت رو غنیمت شمردم و با همون ابزارهایی مثل Multi Media Builder نرم‌افزارهایی برای درس‌های علوم و عربی ساختم. خیلی از فرمول‌ها و روش‌هایی که در کلاس ریاضی یادمون می‌دادن رو با ویژوال بیسیک تبدیل به نرم‌افزار می‌کردم. در همین حین، به سبب تمرکز مدرسه روی مسابقات دانش‌آموزی رباتیک، سی++ هم تا حد خوبی یاد گرفته بودم. از طرفی انتشارات کلید هم «کلید دلفی» رو منتشر کرده بود و این یعنی که در حال یادگیری دلفی هم بودم.

شاید بگید چقدر هندونه؟ خب این همیشه روش من بوده. همیشه هم نتیجه داده و همیشه هم ازش راضیم 😁. شاید بد نباشه که اشاره کنم که همزمان با این ماجرا، به سبب داشتن وبلاگ روی بلاگفا هم کمی جاوااسکریپت (زمانی که جاوااسکریپت هنوز انقدر گسترده نبود) یاد گرفته بودم …

داستان برنامه‌نویس شدن من - محمدرضا حقیری

شروع پروژه جبیر

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

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

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

بگذریم، بهار ۹۱ یک نسخه کاستوم‌شده اوبونتو به اسم «جبیر او اس» منتشر شد که از قضا یک پروژه جنجالی هم شد. اما اثرات جانبی جالبی هم داشت. شاید بتونم مهم‌ترین اثرش رو «ورود رسمی به جامعه نرم‌افزار آزاد» بدونم، اثر دیگرش هم این بود که مدیر مدرسه ما گیر داد که الا و بلا شما باید بیای این رو ببری جشنواره خوارزمی 🙂 بردیمش جشنواره خوارزمی ولی اونجا مقبول نیفتاد. حالا ماجرای خوارزمی رو یک بار باید اساسی‌تر تعریف کنم که در مقوله این مقاله نمی‌گنجه.

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

داستان برنامه‌نویس شدن من - محمدرضا حقیری

و این داستان ادامه دارد …

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

پس، فعلا این پست رو از من داشته باشید و منتظر قسمت بعدی باشید، قسمت بعدی احتمالا خیلی جذاب‌تر خواهد بود 😁

 

Share

نقشه راه بینایی ماشین برای مبتدیان

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

این مطلب، اصلا و ابدا قرار نیست «آموزش» باشه و همونطوری که ابتدای مطلب گفتم، صرفا «نقشه راه» برای شماست.

بینایی ماشین، بینایی کامپیوتری

بینایی ماشین چیه؟

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

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

کجا کاربرد داره؟

کاربردهای بینایی ماشین، می‌تونه در بسیاری از جاها باشه. نمونه‌ش مثلا همین پروژه‌ای که من زده بودم:

اندازه‌گیری اشیا با بینایی ماشین

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

چرا باید بلدش باشیم؟

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

از کجا شروع کنیم؟

خب مهم‌ترین بخش این مطلب دقیقا همینجاست که قراره با هم یاد بگیریم که چه پیش‌نیازهایی برای یادگیری بینایی ماشین وجود داره. هر پیش‌نیاز رو با هم کمی بررسی خواهیم کرد 🙂

  • برنامه‌نویسی پایتون: از اونجایی که پایتون زبان ساده‌ایه و اکثر آدمها دنبال یادگیریشن (و این یعنی منابع آموزشی خیلی خوبی براش هست) بهتره که پایتون رو تا حد خوبی یاد بگیرید. حد خوب، یعنی حدی که شما بتونید یک نرم‌افزار ساده ولی کاربردی رو باهاش توسعه بدید (مثلا یه ماشین حساب یا چیزی مشابه اون).
  • مقدمات یادگیری ماشین: بینایی ماشین به شکلی یکی از زیرمجموعه‌های هوش مصنوعی محسوب میشه. این نشون میده که اگر شما به الگوریتم‌ها و تئوری یادگیری ماشین و … آشناییت کافی داشته باشید، می‌تونید در این فیلد هم پیشرفت قابل توجهی کنید. گذشته از این، یادگیری ماشین می‌تونه بهتون در «هوشمندسازی» بیشتر نرم‌افزارهای بینایی ماشین کمک کنه.
  • آشنایی مختصر با جاوا یا سی++: از اونجایی که پایتون یک زبان مفسری محسوب میشه، ممکنه خیلی‌جاها (مثلا در یک برد آردوینو) نتونیم مستقیم ازش استفاده کنیم و همچنین استفاده ازش پیچیدگی خاصی به همراه داشته باشه؛ بهتره یک زبان سطح پایین‌تر مثل سی++ هم کمی آشنا باشیم. همچنین اگر قصد این رو دارید که اپلیکیشن تلفن همراه بنویسید که از بینایی ماشین استفاده می‌کنه، بد نیست دستی هم در جاوا داشته باشید.
  • آشنایی با سخت‌افزارها و سیستم‌های نهفته (Embedded Systems): یکی از کاربردهای عظیم بینایی ماشین، فعالیت‌های Surveillance می‌تونه باشه (البته این که این فعالیت‌ها بد یا خوب هستند بحث جداییه). یکی از نمونه‌هاش می‌تونه «سیستم حضور و غیاب با تشخیص چهره» باشه، یا حتی «دفترچه تلفن هوشمند» و … 🙂 به همین دلیل، بد نیست که کمی با سیستم‌های نهفته و سخت‌افزارهایی مثل Jetson Nano و Raspberry Pi آشنایی داشته باشید.
  • آشنایی با لینوکس: این واقعا نیاز به توضیح خاصی نداره، روایت داریم اگر لینوکس بلد نیستی، برنامه‌نویس نیستی 🙄

لیست بالا به شما کمک می‌کنه که محکم‌تر در زمینه بینایی ماشین، قدم بردارید. هرجاش رو که بلد نباشید می‌تونید با جستجو پیداش کنید و یاد بگیرید و از یادگیری، لذت ببرید 🙂

سخن آخر

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

Share

از کجا برای پروژه‌های هوش‌مصنوعی و علوم داده، داده مناسب تهیه کنیم؟

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

منابع مناسب داده برای پروژه‌های شما

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

Kaggle

وبسایت کگل، یک محیط تقریبا مشابه شبکه‌های اجتماعی برای دانشمندان داده و متخصصین هوش مصنوعی به حساب میاد. در این وبسایت شما می‌تونید مجموعه داده (Dataset) های خوبی رو پیدا کنید. همچنین، می‌تونید کارهایی که ملت روی اون داده‌ها انجام دادن رو در قالب Kaggle Kernel (به نوعی همون جوپیتر نوت‌بوک خودمون) ببینید و یا کارهای خودتون هم به اشتراک بذارید.

برای دسترسی به کگل، می‌تونید روی این لینک کلیک کنید.

Academic Torrents

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

برای دسترسی به این وبسایت، می‌تونید از طریق این لینک اقدام کنید.

وبسایت دانشگاه‌ها

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

به همین خاطر، وبسایت دانشگاه‌ها – چه ایرانی و چه خارجی – می‌تونه محل خوبی باشه برای مراجعه و پیدا کردن داده‌های خوب برای مطالعه.

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

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

برای مثال، در این لینک می‌تونید دیتاست‌های گوگل رو ببینید. یکی از نمونه‌هایی که خود گوگل اینجا مطرح کرده، دیتاست مرتبط با بیماری کووید-۱۹ است. (لینک)

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

خزیدن (Crawling) صفحات وب

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

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

دوربین، میکروفن، حرکت!

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

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

جمع‌بندی

پروژه‌های هوش مصنوعی به ذات سخت نیستند. چیزی که اونها رو سخت می‌کنه، همین دیتای ورودی و تمیزکاری و مرتب کردنشه. بعضی وقتا داده‌های ما کم هستند و ما مجبور خواهیم شد که Data augmentation انجام بدیم. بعضی وقتا ممکنه نویز به قدری زیاد باشه که اصلا مرحله جمع‌آوری دیتا رو مجبور بشیم دوباره از نو انجام بدیم و … .

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

Share

مهندسی اجتماعی – هوشمندی متن‌باز (OSINT)، خبرسازی

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

هوشمندی متن‌باز (OSINT)

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

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

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

توییتر

چند وقت پیش، در توییتر بحثی به نام «ابر کلمات» داغ بود. افرادی که دسترسی به API توییتر داشتند، برای افراد این ابر کلمات رو میساختند. اما من از اونجایی که حوصله نداشتم با توییتر نامه‌نگاری کنم، دنبال ابزاری بودم که حداقل توییت‌های حساب‌های حفاظت‌نشده رو به سادگی بتونه استخراج کنه. اونجا بود که با ابزار twint آشنا شدم (لینک). ابزار twint یا twitter intelligence ابزاریه که به شما کمک می‌کنه به سادگی در توییتر بچرخید و مثلا توییت‌های یک شخص رو استخراج کنید.

برای مثال، برای این که ۱۰۰ توییت آخر ریاست جمهوری آمریکا رو استخراج کنیم، کافیه دستور تویینت رو به این شکل اجرا کنیم:

twint -u potus --limit 100 -o potus.json --json

به این شکل، ما به سادگی به ۱۰۰ توییت آخر اون حساب کاربری دسترسی داریم.

البته می‌تونیم این دستور رو هی گسترش بدیم و ویژگی‌هایی مثل تاریخ، ساعت، مکان و … هم بهش اضافه کنیم. حالا این کجا به کارمون میاد؟ یه سناریوی خیلی ساده (که مربوط به بخش دوم همین مطلب هم میتونه بشه) رو در نظر بگیرید. مثلا قراره موز گران بشه. شما کافیه که twint رو به این شکل اجرا کنید:

twint -s "گرانی موز" --near Tehran --limit 1000

این هزار توییت آخری که مربوط به «گرانی موز» میشن رو برای ما لیست می‌کنه. می‌تونیم بفهمیم چه کسانی بهش دامن زدند و چه کسانی پیروی کورکورانه کردند و … . خلاصه که اتصال نقاط به یکدیگر خیلی راحتتر میشه.

اینستاگرام

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

البته، اینستاگرام الگوریتم‌های عجیب و غریب زیاد داره و جدیدا APIش هم کمی سخت‌گیر تر شده. ابزاری که برای اینستاگرام پیدا کردم، اسمش هست Osintgram (لینک) و این ابزار رو متاسفانه فرصت نشده که تست کنم هنوز. اما، یک ویدئوی خوب از کانال NetworkChuck براش پیدا کردم که می‌تونید اینجا ببینیدش.

ابزارهای دیگر؟

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

خبرسازی

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

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

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

چطور بفهمیم که قربانی خبرسازی نشدیم؟

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

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

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

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

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

همچنین بخوانید

Share

احراز هویت JWT در روبی آن ریلز

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

احراز هویت JWT چیه و چرا بهش نیاز داریم؟

اول از همه این سوال بنیادی‌تر رو پاسخ بدیم که «چرا احراز هویت نیاز داریم؟» و بعد بریم سراغ احراز هویت JWT که قراره در این مطلب در موردش مفصل حرف بزنیم.

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

پس ما به احراز هویت نیاز داریم که هر ننه‌قمری (😂) نتونه از API ما استفاده کنه. بلکه کاربرانی که ثبت‌نام کردند و دسترسی درستی به سرویس دارند، بتونن استفاده کنن. این قضیه در API های تجاری (یا Business facing) خودشون رو بیشتر و بهتر نشون میدن.

حالا سوال مهم‌تر …

احراز هویت JWT چیه؟

در اپهای قدیمی (مثل همین وردپرس)، احراز هویت توسط cookie ها انجام میشه. به چه صورتی؟ به این صورت که وقتی نام کاربری و گذرواژه وارد می‌کنیم، نرم‌افزار فضایی رو در مرورگر به خودش اختصاص میده و یک سری اطلاعات رو با خودش جابجا می‌کنه. اما در ReST API ها این قضیه رو نداریم. در واقع نمی‌تونیم به کوکی‌ها اعتماد کنیم. پس چه می‌کنیم؟ اینجا لازمه جز یوزرنیم(که معمولا می‌تونه عمومی باشه) و پسورد (که می‌تونه راحت لو بره) میاییم و یک «توکن» هم تعریف می‌کنیم. این توکن، می‌تونه ثابت یا متغیر باشه. یعنی چی؟ یعنی می‌تونه به ازای هربار ورود تغییر کنه، می‌تونه سر زمان مشخصی هم منقضی بشه.

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

حالا در احراز هویت JWT هم، ما به ازای کاربرمون یک توکن در نظر می‌گیریم. این توکن، معمولا یک رشته طولانیه که انسان نمی‌تونه بخوندش. نتیجتا خیلی از اطلاعات ما به صورت ایمن‌تر می‌تونن رد و بدل بشن (طبیعیه که مواردی مثل SSL داشتن و الگوریتم‌هایی که در ساخت توکن داشتیم هم مهمن). ضمن این که نام‌کاربری، ایمیل، رمزعبور و .. هم به همین سادگیا نمی‌تونن خونده بشن.

پس ما می‌آییم و یک دیتابیسی از توکن‌ها در کنار دیتابیسی از یوزرها میسازیم (البته درست‌ترش، جدوله!) و به ازای هر یوزر معمولا دوتا توکن در اون دیتابیس قرار می‌دیم. یکیش رو بهش میگیم «توکن دسترسی» یا Access Token و یکی رو می‌گیم «توکن بازنشانی» یا Refresh Token. توکن دسترسی، معمولا یک تاریخ انقضایی داره و بعد از اون با استفاده از توکن بازنشانی، می‌تونیم یکی جدید بگیریم. اما در آموزش امروز، صرفا میخوایم توکن دسترسی رو به دست بیاریم.

شمایی از کار JWT
احراز هویت JWT به این شکل کار می‌کنه

خب، الان که تقریبا همه‌چی رو می‌دونیم، بریم برای پیاده‌سازی.

پیاده‌سازی یک اپلیکیشن ریلز با JWT

خب در قدم اول، باید یک اپ ایجاد کنیم. این اپ رو به این شکل ایجاد می‌کنیم:

rails new devise-jwt --api

خب توضیح واضحات:

  • قسمت rails که واضحا فراخوانی نرم‌افزار rails در ترمینال ماست.
  • قسمت new در خواست برای ایجاد یک اپ جدیده.
  • قسمت devise-jwt اسم پروژه ماست. حالا چرا؟ چون قراره از یک لایبرری با همین اسم استفاده کنیم. بنابراین، پروژه رو اینطوری اسم گذاشتیم.
  • در قسمت آخر هم، به ریلز گفتیم که ما تو رو بخاطر API هات دوست داریم. ویو نیاز نیست.

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

نصب لایبرری‌های مورد نیاز

خب، اول از همه با ویرایشگر متنی مورد علاقمون فایل Gemfile رو باز می‌کنیم و این خطوط رو بهش اضافه می‌کنیم :
gem 'devise'
gem 'devise-jwt'
gem 'rack-cors'

بعد از این که این خطوط رو اضافه کردیم، دستور زیر رو اجرا می‌کنیم:

bundle

این دستور چه کار می‌کنه؟ میاد و تمام لایبرری‌های مورد نظر شما رو به صورت ایزوله در یک دایرکتوری، نصب می‌کنه. به این شکل شما می‌تونید به سادگی بدون رسیدن آسیب به باقی لایبرری‌های روبی نصب شده روی سرور یا حتی کامپیوتر خودتون، ایده‌هاتون رو تست کنید.

لازم به ذکره که بعد از اجرای این دستور فایل Gemfile.lock به‌روز میشه، این فایل حالا چه کار می‌کنه؟ این فایل حواسش به همه‌چی هست. در واقع، ورژن روبی، ورژن ریلز، لایبرری‌های مورد نیاز و ورژنینگشون و … رو همه رو این فایل داره کنترل می‌کنه.

بعد از انجام مراحل فوق، کافیه این دستور هم اجرا کنیم:

rails g devise:install

این دستور چه می‌کنه؟ این دستور هم برای ما فایلهای devise رو در جای درستش قرار می‌ده.

آشنایی با devise

برای احراز هویت در هر سیستمی ما دو راه داریم:

  • نوشتن سیستم احراز هویت از بیخ
  • استفاده از کتابخانه‌های موجود

در مورد روش «از بیخ»، ما معمولا این کار رو انجام نمی‌دیم. چرا؟ چون معمولا اونقدر خوب نیستیم که بتونیم امنیت سیستم رو به خوبی تامین کنیم. در مورد دوم، در هر فرمورک و زبانی، کتابخانه‌هایی ساخته شدند که کمک می‌کنن ما بتونیم با اضافه کردنشون به پروژه خودمون، بخش احراز هویت رو هندل کنیم. برای ریلز devise ساخته شده. این لایبرری، یک لایبرری مبتنی بر cookie برای احراز هویت وب‌اپ‌هاست.

بعد از همه‌گیر شدن ReST API ها، لایبرری devise-jwt هم نوشته شد. این لایبرری، ابزاریه که به من و شما کمک می‌کنه بتونیم احراز هویت JWT رو به پروژه‌مون اضافه کنیم. در واقع هر سه لایبرری که به پروژه اضافه کردیم، کارشون همینه که JWT رو برای ما راحت کنند.

هندل کردن CORS

در این مطلب قصد ندارم در مورد CORS حرف بزنم، چون قبل‌تر ازش حرف زدم (و می‌تونید اینجا بخونید). اینجا ما صرفا قصدمون اینه که بیاییم و این مشکل رو حل کنیم. چطوری؟ خب این فایل:

config/initializers/cors.rb

رو با ویرایشگر متنی مورد علاقه‌مون باز می‌کنیم، و محتواش رو به این شکل تغییر می‌دیم:

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'

    resource '*',
             headers: :any,
             methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

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

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

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

rails g devise User

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

rails db:migrate

که جدولای مرتبط برامون در دیتابیس ساخته بشن.

حالا که خیالمون از بابت این قضایا راحت شد چی؟ هیچی. دو تا کنترلر هم می‌سازیم به این شکل:

rails g controller users/sessions
rails g controller users/registrations

بعد از این میشه گفت که کار ما اینجا تمام شده و باید بریم یه چیزایی رو ادیت کنیم 🙂

ویرایش مدل یوزر

بعد از این که کارهای بالا رو انجام دادیم، کافیه که بریم سراغ مدل یوزرمون و به این شکل ادیتش کنیم:

class User < ApplicationRecord

  devise :database_authenticatable,
         :jwt_authenticatable,
         :registerable,
         jwt_revocation_strategy: JwtDenylist
end

حالا این کار برای چیه؟ برای اینه که ما یک جدول دیگر به اسم JWT Deny List در نظر می‌گیریم و توکن‌های منقضی‌شده رو درونش قرار می‌دیم. به اون شکل وقتی توکنی منقضی بشه، می‌تونیم به کاربر خطا نشون بدیم یا از توسعه‌دهنده‌های فرانت تیم بخوایم که وقتی اون خطا رو دیدن، کاربر رو لاگ اوت کنن. خلاصه که راه برای رسیدن به نتیجه مطلوب زیاده. بگذریم، بعد از این، در پوشه مدلها لازمه که یک فایل به اسم jwt_denylist.rb ایجاد کنیم و این محتوا رو درونش قرار بدیم:

class JwtDenylist < ApplicationRecord
  include Devise::JWT::RevocationStrategies::Denylist

  self.table_name = 'jwt_denylist'
end

بعد نیاز داریم که برای این قضیه یک مایگرشن اضافه کنیم:

rails g migration CreateJwtDenylist

سپس، فایل مایگرشن که معمولا در آدرس:

db/migrate

قرار داره رو باز می‌کنیم و محتواش رو به این شکل تغییر می‌دیم:

class CreateJwtDenylist < ActiveRecord::Migration[6.1]
  def change
    create_table :jwt_denylist do |t|
      t.string :jti, null: false
      t.datetime :exp, null: false
    end
    add_index :jwt_denylist, :jti
  end
end

و بعد یک دور مایگرشن‌ها رو اجرا می‌کنیم:

rails db:migrate

تا اینجا مطلب طولانی شد؟ ایرادی نداره. بریم یک قهوه بزنیم به بدن و برگردیم 🙂

کنترلر Session

امیدوارم که کافئین به قدر کافی مودتون رو بالا آورده باشه 🙂 حالا وقتشه که بریم و کنترلر session رو درست کنیم. نیازی نیست واقعا کار خاصی کنیم. تنها کاری که نیازه بکنیم اینه که کنترلری که ساختیم رو باز کنیم و این موارد رو درش کپی کنیم:

class Users::SessionsController < Devise::SessionsController
  respond_to :json

  private

  def respond_with(resource, _opts = {})
    render json: { message: 'You are logged in.' }, status: :ok
  end

  def respond_to_on_destroy
    log_out_success && return if current_user

    log_out_failure
  end

  def log_out_success
    render json: { message: "You are logged out." }, status: :ok
  end

  def log_out_failure
    render json: { message: "Hmm nothing happened."}, status: :unauthorized
  end
end

نکته مهم، اگر هنگام ساخت کنترلر، جای users از چیز دیگری استفاده کردید باید Users رو در کد بالا به اون تغییر بدید. اگر هم کلا چیزی نذاشتید، کل قسمت Users:: رو ازش حذف کنید.

کنترلر Registration

خب عین همون بخش قبلی، شما کافیه کنترلر registrations رو باز کنید و این کد رو درونش کپی کنید:

class Users::RegistrationsController < Devise::RegistrationsController
  respond_to :json

  private

  def respond_with(resource, _opts = {})
    register_success && return if resource.persisted?

    register_failed
  end

  def register_success
    render json: { message: 'Signed up sucessfully.' }
  end

  def register_failed
    render json: { message: "Something went wrong." }
  end
end

تنظیمات نهایی devise

خب اول در ترمینال (یا cmd) این دستور رو اجرا کنید:

rake secret

و یک کد طولانی و مسخره بهتون میده 😁 اون رو در فایل:

config/initializers/devise.rb

در آخر فایل به این شکل کپی کنید:

config.jwt do |jwt|
  jwt.secret = rake_secret_output
end

نکته بسیار مهم اینجا چیه؟ این که حواستون باشه این صرفا یک پروژه تسته و برای محیط پروداکشن اصلا جالب نیست که سیکرت‌ها و توکن‌ها، هاردکد باشن. برای اون زمان می‌تونید از ENV استفاده کنید.

مسیرها

خب، الان که تقریبا همه‌چی آرومه و ما چقدر خوشحالیم، کافیه که بیاییم و فایل routes.rb رو هم به این شکل ویرایش کنیم:

Rails.application.routes.draw do
  devise_for :users,
             controllers: {
                 sessions: 'users/sessions',
                 registrations: 'users/registrations'
             }
end

خب پس چی‌ می‌مونه که انجام ندادیم؟ یک سری آزمایش ساده 🙂

ساخت کاربر

خب الان کافیه بعد اجرای سرور ریلز (مطابق آموزش‌های قبلی)، این دستور رو اجرا کنیم:

curl -X POST -H "Content-type: application/json" -d '{ "user": { "email":"test@test.com", "password":"12345678", "password_confirmation":"12345678"}}' http://localhost:3000/users

بعد از اجرای این دستور، یک شیء جی‌سون ساده به این شکل:

{"message":"Signed up sucessfully."}

به ما برمی‌گرده.

دریافت توکن

حالا چطور توکن دریافت کنیم؟ این هم ساده‌ست. فقط کافیه که این دستور رو اجرا کنیم:

curl -X POST -i -H "Content-type: application/json" -d '{"user":{"email":"test@test.com", "password":"12345678"}}' http://localhost:3000/users/sign_in

بعد در خروجی اول به ما چنین چیزی می‌ده:

HTTP/1.1 200 OK
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
Referrer-Policy: strict-origin-when-cross-origin
Content-Type: application/json; charset=utf-8
Vary: Accept, Origin
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIyIiwic2NwIjoidXNlciIsImF1ZCI6bnVsbCwiaWF0IjoxNjIyMTAyOTUxLCJleHAiOjE2MjIxMDY1NTEsImp0aSI6IjBlZDk0YTFmLTgzYTEtNDM3Yy1hOTBkLWQyNTNjY2ZlZDE5YyJ9.NohABuynT-F2GqfCscGtSF6zzK0iAVUIlajSqmMgIMA
ETag: W/"36cb9f6def08029b9c6bff3c14a98017"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: 0584c92c-5100-4acf-8a21-852faa1c0173
X-Runtime: 0.209443
Transfer-Encoding: chunked

که این‌ها سرایند (Header) های ما هستند. در این قسمت، هرچی جلوی Authorization قرار داره توکن ماست. و می‌تونیم ازش استفاده کنیم.

بخش بعدی هم اینه :

{"message":"You are logged in."}

که صرفا به ما می‌گه ورودمون موفقیت‌آمیز بوده.

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

طبیعتا یک قسمت‌هایی از آموزش در این مطلب پوشش داده نشده، سعی می‌کنم در آینده یک یا دو پست تکمیلی هم ارائه کنم که همه این قضایا به خوبی پوشش داده بشه (یا این که کلا در بخش ویدئویی در خدمتتون باشم).

به صورت کلی، دوست دارم بدونم نظر شما در مورد این تیپ آموزش‌ها چیه؟ آیا ادامه‌شون بدم یا خیر؟ و این که آیا پایه‌ش هستید که بحث فرانتند رو هم شروع کنیم یا روی همین بکند باقی بمونیم و اول یه پروژه کامل رو بکندش رو بزنیم و بعد بریم سراغ فرانت؟ 🙂

در آخر هم بابت وقتی که گذاشتید و مطلب رو خوندید ازتون متشکرم.

Share

ساخت REST API در روبی آن ریلز – قسمت دوم

در پست قبلی با هم یک REST API نوشتیم که یک نمونه از مدل «پست» رو می‌تونست ایجاد کنه، بروز کنه، نمایش بده و نابود کنه.

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

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

بیاییم ببینیم تیم محصول برای ما چی طراحی کرده. این عزیزان در نظر دارند که هر کامنت صرفا یک «متن بدنه» داشته باشه و بیشتر از اون نیاز نداشتند. کار ما اینه که حالا مدلی طراحی کنیم که علاوه بر اون، به پست‌ها هم ربط داشته‌باشه. چطوری این کار رو می‌تونیم بکنیم؟

کافیه دستور زیر رو اجرا کنیم و مدلش رو بسازیم:

rails generate model Comment body:text post_id:integer

خب حالا میریم به پوشه :

app/models

و اول post.rb رو به این شکل ویرایش می‌کنیم:

class Post < ApplicationRecord
    has_many :comments 
end

و سپس comment.rb رو به این شکل ویرایش می‌کنیم:

class Comment < ApplicationRecord
    belongs_to :post 
end

حالا این خطوط چی میگن؟ ما در پایگاه داده چندین نوع رابطه داریم. توضیح این روابط به صورت مفصل باشه برای یک پست دیگه. اما اینجا بیاید در نظر بگیرید که طراحی محصول به شکلی بوده که «هر پست میتونه بی‌شمار کامنت داشته باشه و هر کامنت متعلق به فقط و تنها فقط یک پسته». این نوع رابطه اسمش هست «یک به چند» یا بهتر بگم «یک به خیلی» و به قول خارجی‌ها One to many.

حالا که از این قضیه خبر داریم و پست رو هم ساختیم تعلل نمی‌کنیم. می‌ریم سراغ ساخت کنترلر مربوطه. اینجا کنترلر به ما کمک می‌کنه که بتونیم به سادگی یک کامنت رو روی پست بسازیم و مدیریت کنیم. در مورد سناریوی کنترل کامنت هم این بار کمی ساده‌تر می‌گیریم. در ادامه این مورد رو با هم بررسی خواهیم کرد.

ساخت کنترلر کامنت

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

rails generate controller api/v1/comments

و سپس در فایل:

config/routes.rb

این تغییر ریز رو ایجاد می‌کنیم :

Rails.application.routes.draw do
  namespace :api do
    namespace :v1 do
      resources :post do 
        resources :comments
      end
    end
  end
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
end

و بعد میریم سروقت کنترلر 🙂 اما قبل از اون بیاید یه چیزی رو بررسی کنیم. این روابط رو! این روابط چطوری تعیین شدند؟ و چرا مهمند. پس در ترمینالمون تایپ می‌کنیم:

rails c

این دستور، به ما یک «کنسول ریلز» میده. کنسول به ما کمک می‌کنه که ایده‌ها رو در یک لول قبل از مرورگر و درخواست‌های HTTP بررسی کنیم. در اسکرین‌شات زیر از ترمینال من، می‌بینید که چطوری یکی از پست‌ها رو تست کردم و دیدم که آیا روابطش با کامنت‌ها درسته یا خیر.

خب حالا بیاییم کنترلر رو بنویسیم. قبل از اون، من یک کامنت دستی در کنسول به این شکل می‌سازم:

c = Comment.new(:body => "This is a comment", :post_id => 1)
c.save

و کنسول رو می‌بندم. می‌ریم سراغ کنترلرمون. همونطور که گفتم اینجا یه سری چیزا نیستن. مثلا show اینجا نیازی نیست باشه ولی index نیاز هست. پس می‌ریم سراغ این که این موارد رو در کنترلر لحاظ کنیم. خب با توجه به این توضیحات، ما یک متد index به این شکل نیاز داریم:

def index
    @post = Post.find(params[:post_id])
    render json: @post.comments
end

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

curl -X GET -i http://localhost:3000/api/v1/post/1/comments

حالا وقتشه که بتونیم یک کامنت جدید ایجاد کنیم. برای ساخت کامنت جدید هم کافیه که به این شکل، متد create رو بنویسیم:

def create
        @comment = Comment.new(:body => params[:comment][:body], :post_id => params[:post_id])
        if @comment.save 
            render json: {:status => "success", :comment => @comment}
        end 
    end

و نمونه درخواستی که براش می‌فرستیم هم به این شکل:

curl -X POST -H 'Content-Type: application/json' -i http://localhost:3000/api/v1/post/1/comments --data '{
"body":"This is another comment"
}'

حالا یک سوال مهم ممکنه برای شما پیش بیاد و اون هم اینه که :

چرا پارامترهای ارسالی فرق دارند؟

دلیلش خیلی ساده‌ست. ریلز اول میاد پارامترهای درون URL رو مستقیم میخونه، بعد میاد سراغ Request Body که در واقع اگر سلسله مراتبی (مثل یک فایل YAML) بهش نگاه کنیم این شکلی میشه:

- post_id: 1
- comment:
    - body: "This is another comment"

در واقع برای خودش یک Resource space در نظر می‌گیره و body رو از اون میخونه. به همین خاطره که یکی زیرمجموعه comment و دیگری مستقیما post_id میشه.

باقی متدها چی؟

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

جمع‌بندی دو قسمت اخیر

خب در این دوقسمت ما خیلی چیزا یاد گرفتیم که فهرست‌وار بررسی می‌کنیم :

  • چطور ریلز نصب کنیم.
  • چطور یک پروژه ریلز جدید ایجاد کنیم.
  • چطور یک منطق تجاری (Business Logic) رو درک کنیم
  • چطور مدل‌های مورد نظر رو بسازیم
  • چطور API بسازیم و تست کنیم.

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

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

در آخر، از شما بابت وقتی که برای خوندن این مطلب گذاشتید هم کمال تشکر رو دارم.

Share

مزایا و معایب معماری MVC در توسعه نرم‌افزار

در پست قبلی، بررسی کردیم که اصلا 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

و خب وارد جزییات نمی‌شم، میتونیم جزییات مدل رو در فایلهای مربوطه بررسی کنیم.

بعد برای این مدل به این شکل می‌تونیم کنترلر بسازیم:

php artisan make:controller --resource --model=Post

البته لازم به ذکره که باید دقت داشته باشید همیشه کنترلرها از جنس resource و CRUD نیستن و این دو راهکار، در واقع برای وقتی خوبن که شما نیازمند CRUD باشید و نخواهید هزینه ساخت کنترلر «از بیخ» رو متحمل بشید.

جمع‌بندی مطالب

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

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

Share

معماری MVC همراه با مثال در ریلز

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

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

معماری MVC یعنی چی؟

خب MVC یک مخففه برای Model, View و Controller. در این معماری، یک نرم‌افزار (یا بهتره بگیم ایده/بیزنس) رو به سه موجودیت مدل، ویو و کنترلر تقسیم می‌کنیم و هر قسمت ایده یا بیزنس رو به یکی از اینها تبدیل می‌کنیم. در واقع، فرمورکها اینجان که ما فرایند ساخت این قضایا رو سریع‌تر پیش ببریم.

پس، بهتره جای این که صرفا دنبال زیربغل مار بگردیم، هر موجودیت رو جدا تعریف کنیم و ببینیم تهش به چی می‌رسیم!

مدل – Model

مدل، همونطور که از اسمش پیداست؛ یک مفهوم انتزاعی از یک موجودیته. بذارید یک مثال ببینیم. بیاید یک پست وبلاگ رو بررسی کنیم.

پست وبلاگ چیا داره؟ پست وبلاگ در نظر من اینها رو حتما داره:

  • عنوان که به عنوان یک رشته متنی در نظر گرفته میشه.
  • عنوان کوتاه یا slug که این هم یک رشته متنی در نظر گرفته میشه.
  • متن بدنه یا body که «متن» در نظر گرفته میشه.

توجه کنید که text از نظر اکثر فرمورکها با string متفاوته. این تفاوت رو احتمالا در مستندات فرمورکی که باهاش کار می‌کنید میتونید پیدا کنید.

حالا این مدل رو چطوری میسازیم؟ در ریلز به این صورت می‌تونیم یک مدل بسازیم:

rails generate model Post title:string slug:string body:text

بعد از اون هم به این شکل مایگرشن‌ها رو اجرا می‌کنیم:

rails db:migrate

خب الان چی داریم؟!

الان چیزی نداریم جز یک مدل، که صرفا میگه «تعریف من از پست چیه». این تعریف کجا استفاده میشه؟ در دیتابیس. خب پس یعنی چی؟ بیاید یک تعریف کلی از مدل ارائه کنیم:

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

خب، الان که می‌دونیم مدل چیه، چطور می‌تونیم یک نمونه ازش اجرا کنیم؟ برای نمونه در ریلز، ما اول کنسول ریلز رو باز می‌کنیم:

rails c

و سپس این دستور رو در کنسول وارد می‌کنیم:

Post.create(:title => "Hello, World", :slug => "hello-world", :body
 => "This is a first post made the wrongest way possible")

و به این شکل، ما یک پست ساختیم. اما آیا روش بهتری هم هست؟ بله هست!

کنترلرها – Controllers

طبیعتا وقتی به شما یک API داده میشه، از شما نمی‌خوان که با دستورات روبی پست بسازید، به‌روز کنید یا حذف کنید! چیزی که به شما میدن چنین چیزیه:

GET /api/v1/posts

و این باید لیست همه پست‌ها رو برگردونه. پس چطور این اتفاق می‌افته؟ با موجودیتی به اسم «کنترلر». کنترلر کارش چیه؟ کنترلر همونطور که از اسمش پیداست، میتونه کنترل کنه (یا بعبارتی چطور چشم‌بسته غیب بگیم؟). کنترلر وظیفه‌ش انجام عملیات CRUD روی مدله.

حالا CRUD چیه؟ این هم یه مفهومی در بطن MVC و Rest API عه که باید بدونید چی به چیه و چی کار می‌کنه. عبارت CRUD مخفف Create, Restore, Update و Destroy عه. بیاید با هم دقیق بررسی کنیم:

  • حرف C یا Create : یعنی کنترلر باید بتونه برای من، یک نمونه از مدلم رو بسازه.
  • حرف R یا Restore (که در بعضی منابع Retrieve هم گفتن) : یعنی کنترلر باید بتونه محتوای یک مدل یا همه مدلها رو به من نشان بده.
  • حرف U یا Update : یعنی کنترلر باید بتونه در وضعیت یک نمونه از مدل، تغییری ایجاد کنه.
  • حرف D یا Destroy : یعنی کنترلر باید بتونه یک نمونه از مدل رو حذف کنه.

شما همون پست بلاگ رو در نظر بگیرید. این پست ممکنه نیاز داشته باشه که ویرایش بشه، نیازمند اینه که گاهی حتی حذف کامل بشه و … . این کار رو با کنترلر انجام می‌دیم. حالا چطوری یک کنترلر می‌سازیم؟ به این شکل:

rails generate controller api/v1/posts

سپس درون فایل کنترلر، این دو تابع رو برای حرف R اضافه می‌کنیم:

def index
    @posts = Post.all 
    render json: @posts
end

def show 
    @post = Post.find(params[:id])
    render json: @post 
end

در یک تابع، قراره که کل پست‌ها رو ببینیم و در یکی، فقط اونی که با ID مورد نظر ما درخواست شده نمایش داده میشه. خب، الان کافیه با ابزاری مثل curl تست کنیم API مون رو.

 ~/playground/mvc-tutorial/ [master] curl http://localhost:3000/api/v1/posts/1
{"id":1,"title":"Hello, World","slug":"hello-world","body":"This is a first post made the wrongest way possible","created_at":"2021-03-23T16:19:41.950Z","updated_at":"2021-03-23T16:19:41.950Z"}

حالا جهت این که C هم ببینیم، اون هم به کنترلر مربوطه اضافه می‌کنیم، اما بقیه‌ش رو از مستندات ریلز می‌تونید یاد بگیرید 😁

پس این تابع رو به فایل کنترلرمون اضافه می‌کنیم:

def create 
        @post = Post.new(post_params)
        if @post.save 
            render json: {:post => @post, :status => success}
        else 
            render error: {:error => "Failed"}
        end 
end

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

با ابزار curl به این شکل می‌تونیم از این بخش کنترلر استفاده کنیم:

curl -X POST -H 'Content-Type: application/json' -i http://localhost:3000/api/v1/posts --data '{
 "title":"A post from a request",
 "slug":"a-post-from-a-request",
 "body":"This post has been create using an API call, to show you how awesome MVC can get!" 
}'

البته حواستون باشه در این مورد، حتما باید هدر Content-Type رو ارسال کنیم.

این هم نمونه جوابی که این تابع باید به ما بده:

{
  "post": {
    "id": 2,
    "title": "A post from a request",
    "slug": "a-post-from-a-request",
    "body": "This post has been create using an API call, to show you how awesome MVC can get!",
    "created_at": "2021-03-23T17:37:55.502Z",
    "updated_at": "2021-03-23T17:37:55.502Z"
  },
  "status": "success"
}

 

اما خب، چطوری این داده رو میتونیم همینجا ببینیم؟! بدون این که از curl و … استفاده کنیم؟

ویوها – View

در بخش پیش، کنترلرها رو با دیدی که برای API و … داریم ساختیم. برای استفاده از ویو، یک بار دیگه یه کنترلر میسازیم:

rails generate controller posts

در این کنترلر این دو تابع رو قرار می‌دیم:

def index
    @posts = Post.all 
end

def show 
    @post = Post.find(params[:id])
end

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

قابل خواندن برای ماشین (Machine Readable) : این مفهوم، به معنای داده‌هاییه که صرفا برای کامپیوتر قابل درک و خواندن هستن و برای کاربر، خواندنشون مشکله. مثل خروجی JSON یا چیزایی که تو دیتابیس ذخیره می‌کنیم. وقتی از روی API داده‌ای می‌فرستیم، در واقع داده‌ها رو به صورت قابل خواندن برای ماشین می‌فرستیم و دریافت می‌کنیم.

قابل خواندن برای انسان (Human Readable) : این مفهوم، به معنای داده‌هاییه که برای انسان قابل خوندن هستند. مثل همین پستی که شما دارید میخونید. در واقع این پست در یک دیتابیس MySQL به شکل عجیب و غریب (برای انسان) ذخیره شده و وقتی شما روی لینکش کلیک می‌کنید، به شکل قابل خواندن برای انسان درمیاد.

اگر صرفا API داشته باشیم، کار ما MVC نیست، اما میتونیم ویو رو با استفاده از Front End داشته باشیم (که در آینده در مورد اون هم یک مطلب خواهم نوشت). اما میتونیم بیایم و برای حداقل همون حرف R یک ویو بسازیم (در حقیقت دو تا). چرا؟ چون بعضی وقتا ممکنه برنامه‌نویس فرانت نداشته باشیم، بعضی وقتا ممکنه حتی نیازی به فرانت نباشه و … .

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

app/views

یک پوشه به اسم کنترلر مربوطه ساخته میشه. پس در پوشه:

app/views/posts

دو فایل به اسم‌های index.html.erb و show.html.erb ایجاد می‌کنیم.

در فایل index.html.erb این موارد رو باید داشته باشیم:

<h1> Posts </h1>
<% for post in @posts %>
    <ul>
        <li>
            <a href="/posts/<%= post.id %>"> <%= post.title %></a>
        </li>
    </ul>
<% end %>

همونطور که می‌بینید، این کد دو تفاوت اساسی با HTML معمولی داره :

  • پسوندش یه ERB اضافه داره
  • کد روبی وسطش زده شده.

خب، این زبون، HTML نیست (بله، HTML هم زبانه، فقط «زبان برنامه‌نویسی» نیست!) بلکه زبان تمپلیتینگ خود روبیه. مثل blade در php یا Jinja در پایتون.

در show.html.erb هم این کد رو قرار می‌دیم:

<h1> <%= @post.title %> </h1> 
<h2> Slug: <%= @post.slug %> </h2 >
<h2> Body: </h2>
<p> 
    <%= @post.body %>
</p>

حالا اگر با مرورگر به localhost:3000/posts بریم این صحنه زشت رو می‌بینیم 😁

و اگر روی لینک‌ها کلیک کنیم، وارد پست‌ها می‌شیم:

البته یادتون باشه slug معمولا برای url کاربرد داره ولی چون اینجا قصد آموزش ریلز نبود، از این ماجرا صرف نظر کردیم.

خب، حالا بعد یک مطلب طولانی، می‌دونیم که چی به چیه؛ بیاید با هم جمع‌بندی کنیم.

جمع‌بندی مطلب

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

  • مدل : مدلها، تعاریف انتزاعی از موجودیت‌ها، ویژگی‌ها و روابط بینشون هستند. به عبارتی، شکلی که ما قراره داده خام رو پردازش کنیم، در مدل تعیین میشه. کمی راحت‌ترش کنم؟ مدل در واقع ساختار دیتابیس ماست.
  • کنترلر : کنترلر وظیفه ساخت یک نمونه از مدل، استخراج داده از دیتابیس، بروزرسانی داده در دیتابیس و حذف یک رکورد از دیتابیس رو عهده داره. این هم اگر بخوام راحت توصیف کنم، میگم ابزاری که باهاش دیتابیس رو به شکل ساده‌تری کنترل می‌کنیم.
  • ویو : ویو، نتیجه یک کوئری رو به صورت قابل خواندن توسط انسان، به ما نمایش میده. نتیجه کوئری معمولا به صورت یک جدول در دیتابیس (در واقع یک یا چند سطرش) یا به صورت JSON برمی‌گرده که توسط انسان قابل خوندن نیست. ما در ویو (و البته اغلب فرانت) این اتفاق رو رقم می‌زنیم.

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

در پایان، از همه شمایی که این مطلب رو خوندید تشکر می‌کنم که وقت گذاشتید بابت خوندن مطلب. ضمنا، این اتفاقات در فرمورکی که شما استفاده می‌کنید چطوری رقم میخوره؟ در نظرات منتظرتونم 🙂

Share