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

مصاحبه با محمدرضا حقیری، مهندس هوش مصنوعی

ما با محمدرضا حقیری، توسعه‌دهنده‌ای از ایران که هم‌اکنون مشغول کار بر روی یک مدل متن به تصویر متن‌باز به نام مانی است، صحبت کردیم.

او دانشش درباره فناوری‌هایی که برای توسعه این مدل استفاده کرده را با ما به اشتراک گذاشته است. هوش مصنوعی چندمدلی او، از Stable Diffusion و Dream Booth استفاده می‌کند.

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

لطفا خودت رو برای خوانندگان ما معرفی کن. چه کارهایی کردی که به اینجا رسیدی؟ و چطور؟

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

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

اواخر ۲۰۲۱ و اوایل ۲۰۲۲ بود که مفهوم «هوش مصنوعی مولد» و «هنر تولیدشده توسط هوش مصنوعی» رو شناختم و همونطوری که می‌تونی حدس بزنی، عاشقش شدم 😁 به همین خاطر هم مطالعاتم جدی‌تر شدند و سعی کردم مدل خودم رو در قالب یک استارتاپ توسعه بدم تا بتونم اون چیزی که در ذهن دارم رو تولید کنم.

در حال حاضر روی مدل متن به تصویری به اسم Mann-E کار می‌کنی. می‌تونی یکم در موردش توضیح بدی و بگی چطور کار می‌کنه؟

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

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

اگر دوست دارید بدونید چطور می‌تونید از مانی استفاده کنید، می‌تونید به گیتهاب من مراجعه کنید. یک دفترچه یادداشت جوپیتر اونجا هست که می‌تونه به Google Colab وارد بشه. حجم زیادی از کد هم از دید کاربر مخفی شده که حسی مشابه Midjourney یا Dall-E داشته باشه.

تو وبلاگت اشاره کردی که مدل بر مبنای Stable Diffusion ساخته شده. چه فناوری‌هایی برای این هوش مصنوعی استفاده کردی؟

این چیزیه که من بهش میگم «سوال مورد علاقه‌م». می‌تونم ساعت‌ها در مورد فناوری‌هایی که استفاده کردم، صحبت کنم. اول بذارید یک تاریخچه‌ای براتون بگم. وقتی اکثر تولیدکنندگان تصویر خوب «آزاد» نبودند (در مصاحبه گفتم free و ظاهرا یادم رفته مشخص کنم free as in freedom) تنها پایه و مبنای خوب برای یک تولیدکننده اثر هنری با کمک هوش مصنوعی VQGAN بود. یادمه که اگر نتایجش رو با CLIP ترکیب می‌کردی می‌تونست نتایج خوبی ارائه بده. در واقع این یک بازی انکودر-دیکودر بین دوتا مدل هوش مصنوعی بود.

ولی به قدر کافی خوشحال‌کننده نبود، مخصوصا این که midjourney در همون نسخه‌ها هم تصاویری تولید می‌کرد که انگار همین الان از ذهن یک هنرمند چیره‌دست بیرون آمده. پس من چه کردم؟ شخصا به این فکر بودم که چه اتفاقی می‌افتاد اگر یک نسخه متن‌باز از Midjourney داشتیم؟ و همزمان افرادی در شرکت Stability AI هم فکر مشابهی داشتند. وقتی انتشار Sable Diffusion رو اعلام کردند، من واقعا خوشحال شده بودم. کانسپت رو واقعا دوست داشتم با خودم گفتم که این به درد پروژه من هم میخوره! اینجا دقیقا جایی بود که من رفتم هرچی مقاله و تحقیق در مورد Stable Diffusion بود رو خوندم. این برای من یک دنیا ارزش داشت، چون بالاخره یک مدل تولید تصویر بسیار خوب داشت منتشر می‌شد.

این Stable Diffusion فناوری ابتدایی من بود. بی‌نهایت دوستش داشتم. همیشه تلاش می‌کردم بهترین نتایج رو ازش بگیرم. از prompt engineering صرف بگیر تا نوشتن کد‌هایی که بتونه برای من نتایج بهتری ازش بگیره. در ماه‌هایی که از انتشار نسخه اولیه‌ش گذشت، دو تا اتفاق خیلی بزرگ افتاد. اول این که Dream Booth برای Stable Diffusion ریلیز شد ( و صادقانه بخوام بگم، فاین تیون کردن Stable Diffusion رو به شدت ساده کرده) و همزمان RunwayML هم ورژن ۱.۵ از Stable Diffusion رو منتشر کرد. من مواد اولیه اصلی برای ساخت Midjourney متن‌باز رو داشتم!

بخوام خلاصه بگم: هسته اصلی Stable Diffusion ئه، از چک‌پوینت‌های نسخه ۱.۵ ای که runwayml ساخته استفاده کردم و تیون/ترین کردن با Dream Booth انجام شده. اینا Mann-E رو ممکن کردند. همچنین زبان‌های مورد استفاده هم باید بگم که عمدتا از پایتون استفاده کردم و کمی هم کد روبی برای توسعه وب نوشتم. و این تمام چیزیه که من استفاده کردم.

چه تفاوتی با Dall-E, Open Journey و باقی مدل‌ها داره؟

این سوال سختیه، بخصوص که در طول سال گذشته هزاران مدل با تکنیک‌های Textual Inversion و Dream Booth منتشر شدند. ولی اگر بخوام خلاصه بگم که چه فرقی با Dall-E داره، باید بگم که مانی به اون اندازه گرون نیست. برای استفاده از مانی، فقط کافیه که Google Colab رو راه‌ بندازید، نوت‌بوک رو واردش کنید و تمام! می‌تونید بی‌نهایت تصویر باهاش بسازید. این رو با Dall-E مقایسه کنید که به شما ۵۰ تا تصویر رایگان می‌ده و بعدش باید هزینه پرداخت کنید (که البته به نظرم مدل درآمدی بدی نیست).

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

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

روی مدلی به نام Open Journey کار می‌کردی ولی اسمشو عوض کردی. می‌تونی کمی در موردش بگی؟

مانی اول کار، اسم مدل نبود؛ بلکه اسم استارتاپی بود که در تابستان ۲۰۲۲ برای همین کار راه انداخته بودم. اسم مدل Open Journey بود که اشاره به Open Source Midjourney داشت. بعدا، فهمیدم که یک نفر از تیم میدجرنی از تیم prompthero خواسته که اسم مدلشون (که فکر کنم چیزی مثل midjourney-v4-style-stable-diffusion یا چنین چیزی بود) رو عوض کنند و اون‌ها (یعنی prompthero) هم اسم مدل رو به OpenJourney تغییر دادند. من ازشون درخواست کردم که اسم مدل رو عوض کنند ولی از اونجایی که ترجیحم این بود که اون استارتاپ رو در اون برهه زمانی متوقف کنم، اسم مدل رو به مانی تغییر دادم.

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

فکر می‌کنی آینده هوش مصنوعی چطوریه؟ حرف و حدیث در مورد موضوع خیلی زیاده و اکثرا ریشه در محصولات شرکت OpenAI مثل ChatGPT داره. اتفاق بعدی چیه؟

باور دارم که هوش مصنوعی آینده‌ست. برخلاف چیزی که سال ۲۰۲۱ اومد و یه فازی ساخت و رفت (و بله، منظورم متاورس زاکربرگه). هوش مصنوعی واقعی و آینده‌داره. من دارم به چشم می‌بینم که افراد زیادی از این ابزارها برای تولید پست‌های بلاگ، کپی‌رایتینگ، تولید شعار برای شرکت و استارتاپ، تولید آیکون و تصویر شاخص و حتی تولید کد استفاده می‌کنند. این خیلیه، بخصوص با وجود ابزارهایی مثل GPT-3 یا ChatGPT حتی می‌تونه رایج‌تر هم بشه. از طرف دیگر قضیه هم که بخواهیم نگاه کنیم، ابزارهای متن‌بازی مثل BLOOM, BLOOMZ, Flan-T5, GPT-Neo و … رو داریم. افراد می‌تونند این مدل‌ها و API رو متناسب با نیازهای خودشون، تغییر بدند.

و باور دارم که ابزارهای هوش مصنوعی ما را به جهانی هل می‌دهند که مردم در آن هوشمندانه‌تر کار می‌کنند، نه سخت‌تر. می‌دونی، تو می‌تونی شونزده ساعت از بیست و چهار ساعت شبانه روز رو صرف توسعه یه کمپوننت تو پروژه ری‌اکتیت کنی، درسته؟ این خیلی خوبه که شغلت و کاری که می‌کنی رو دوست داره ولی حدس من اینه که این ماجرا برای کارفرما یا سرمایه‌گذار هیچ اهمیتی نداره، بخصوص وقتی می‌فهمن که با ۱۶ دقیقه prompt engineering می‌تونستی همون نتیجه رو از GPT-3 با کمی ویرایش کد بگیری. برای من، این یک دنیای بهتره.

در پایان هم از تو، الکساندر؛ تشکر می‌کنم که اومدی سراغم.

سخن آخر

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

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

احتمالا اگر با فرمورک‌هایی مثل جنگو، ریلز یا 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 هم حرف بزنم. یک اتفاق بامزه هم این وسط افتاد که من حتی مجبور شدم لپتاپ رو ریبوت کنم و شانس آوردم که دو سه ساعت فکر و نوشتن، نپریده بود 😂

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

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

چه شد که این پروژه رو شروع کردم؟

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

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

مفهوم تازه : CORS

خب، وقتی که ما بکند و فرانتند پروژه رو از هم جدا می‌کنیم، در واقع داریم دوتا origin مختلف رو به هم وصل می‌کنیم. طبق استانداردهای وب؛ اصولا چنین کاری در مرورگرها؛ بخاطر مسائل امنیتی مجاز دونسته نشده. به همین خاطر، ما مفهوم تازه‌ای به اسم «چند ریشه‌ای» یا Cross-Origin رو خواهیم داشت.

حقیقتا وقتی فرانتند رو با جاوااسکریپت می‌نوشتم؛ دیدم که یک سری ارور بهم میده و توی اون ارورها بهم میگه که بکند من، برای «اشتراک گذاری منابع چندریشه‌ای» یا Cross-Origin Resource Sharing تهیه نشده. دوست داشتم از خود کد جاوااسکریپتم درستش کنم اما چون قرار بود روی هاست همین وبلاگ قرار بگیره و نه سرور مجزایی؛ ترجیح دادم که به جای node.js از وانیلا جی اس استفاده کنم (توضیح : وانیلا اصطلاحا به نرم افزار یا ابزار دست نخورده گفته میشه) و خب راهکاری براش پیدا نکردم (شاید هم چون درست دنبالش نگشتم) ولی از اونجایی که بکند رو با روبی و سیناترا نوشته بودم، براش راهکار پیدا کردم و این راهکار رو در یک ویرگول به اشتراک گذاشتم (لینک).

همین یک کار کوچک، باعث شد که من مفهوم کورز و صد البته نحوه کانفیگ درستش در بکند رو یاد بگیرم، از این جهت هم واقعا خوشحالم چرا که اکثر توسعه دهنده های فرانت، مدام از این قضیه که در بکند این مشکل حل نمیشه، نالانند ((:

چیزی که سالها عقبش انداخته بودم : زرین پال!

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

از وقتی به سن قانونی رسیدم هم هرروز میخواستم برم و اکانت زرین پال درست کنم تا ازش برای حمایت و فروش و … روی اینترنت استفاده کنم. خلاصه که بالاخره همزمان با ریلیز این پروژه، این اتفاق هم افتاد ((: تازه دقیقتر بخواهیم حساب کنیم، برای این مساله هم مجبور شدم کارت بانکیم رو تمدید کنم و هم برای کارت هوشمند ملی اقدام کنم!

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

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

کد

class Node
 attr_accessor :node, :next
 
 def initialize(node)
  @node = node
 end
end

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

کد

def self.node_list(node, msg = nil)
    msg ||= ""
    return msg[0..-4] if node.nil?
    node_list(node.next, msg << "#{node.node} -> ")
  end

بسیار خوب! حالا یک متدی مینویسیم که این لیست رو برای ما، برعکس کنه. گرچه چنین متدی نیاز نیست، اما چون توی روبی از این متد برای هش ها و لیست ها (آرایه ها) استفاده شده، بهتره ما هم به لینک لیستمون اضافش کنیم. خب یک متد هم به اسم Reverse ایجاد میکنیم به این شکل:

کد

def self.reverse(node)
    return node if node.next.nil?
 
    head, swap, node.next = node.next, node, nil
    link = head.next
 
    while link != nil
      head.next = swap
      swap = head
      head = link
      link = link.next
    end
 
    head.next = swap
    head
  end

حالا میتونیم با استفاده از این کلاس، از لیست های پیوندی استفاده کنیم. البته دقت کنید که ما در اینجا در مورد حذف و اضافه کردن Node ها حرفی نزدیم. بلکه صرفا نمایش و معکوس کردن لیست رو بررسی کردیم. امیدوارم کد به کمکتون اومده باشه :).

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

برنامه Hello World

کد

puts "Hello, World"

چقدر فرق با روبی حس کردید؟ درسته! هیچ فرقی با روبی نداره. مثالهای بعدی هم هیچ فرقی ندارند.

برنامه شرطی (چک کردن سن قانونی)

کد

if age >= 18
 puts "Legal"
else 
 puts "Not Legal"
end

استفاده از حلقه (برنامه چاپ اعداد ۰ تا ۱۰)

کد

n = 0
while n <= 10
 puts n
 n += 1
end

برنامه شیء گرا (نوشتن کلاس Greeter )

کد

class Greeter
 def initialize(name)
  @name = name
 end
 
 def say_hi
  puts "Hello, I am #{@name}"
 end
end

کد ها رو دیدید؟ خیلی خوب! اگر دوست دارید که این ها رو به نیتیو کد تبدیل کنید همین الان به وبسایت کریستال (که ابتدای پست لینک دادم) مراجعه کنید و شروع به خوندن داکیومنت هاش کنید. مطمئنا کوچکترین تفاوتی در ظاهر با روبی نداره و از این جهت، روبیست ها میتونن به سادگی یادش بگیرند.