ستراكوفسكي يطلق Hifumi لإنشاء تطبيقات Rails كاملة عبر الوكلاء الأذكياء

Ruby on Rails

اتفاقيات إطار عمل Rails الممتدة لعشرين عاماً وثقافة الاختبار المسبق تجعلان بيئته الأكثر ملاءمة للبرمجة الذاتية مقارنة بمنظومة جافاسكريبت السائدة.

AI-assisted summary of From Prompt to Rails: An Online Rails App Generator - Paweł Strzałkowski — original source. Check the original for full context.

Source published: 2026-10-01

Key ideas

إطلاق منصة Hifumi مفتوحة المصدر (hifumi.dev) لتوليد تطبيقات ويب حية وكاملة مبنية على إطار Ruby on Rails بدلاً من بيئات JavaScript الشائعة في مولدات الأكواد الحالية. (3:16)
تعتمد المنصة على سير عمل مهيكل تقوده أداة Roast المطورة من Shopify بالتكامل مع RubyLLM وClaude Code لتقسيم عملية التطوير إلى مراحل مراجعة (Revisions) دقيقة ومحكمة. (10:59)
تنفيذ كل مرحلة بناء داخل حاوية Docker مؤقتة تُحذف فورياً (`--rm`)، مع تطبيق فحوصات حتمية واختبارات تكاملية حالت دون الحاجة للتراجع التلقائي للكود طوال ثلاثة أشهر من التجارب. (15:24)
توفير نظام معاينة تفاعلية حية يربط بين Docker وKamal Proxy وفحص الجاهزية `/up`، مع بث الواجهة مباشرة للمستخدم داخل إطار iframe بالاعتماد على Solid Queue وHotwire. (17:30)

Detailed notes

## Background نُشر هذا العرض التقديمي عبر قناة Ruby on Rails الرسمية على منصة YouTube في 1 أكتوبر 2026 برعاية شركة Shopify، ويقدمه المهندس باويل ستراكوفسكي (Paweł Strzałkowski). يستعرض الفيديو مشروع Hifumi، وهو مولد تطبيقات مفتوح المصدر يحول الأوامر النصية إلى تطبيقات متكاملة مبنية بإطار Ruby on Rails بدلاً من JavaScript، متناولاً دورة التطوير الكاملة من التخطيط والتنفيذ عبر الوكلاء في حاويات Docker وصولاً إلى المعاينة المباشرة والتصدير إلى GitHub.

## TL;DR يستعرض باويل ستراكوفسكي منصة Hifumi التي تهدف لكسر هيمنة منظومة JavaScript على مولدات التطبيقات المدعومة بالذكاء الاصطناعي وجلب قوة إطار Ruby on Rails للمستخدمين والمطورين. يشرح العرض كيفية تحويل الفكرة الأولية إلى خطة تنفيذ متعددة المراحل تُدار عبر Roast وRubyLLM، وتُنفذ برمجياً باستخدام Claude Code داخل حاويات Docker معزولة ومؤقتة. يتطرق الحديث أيضاً إلى معمارية الفحص الذاتي، ونظام المعاينة الحية المعتمد على Kamal Proxy وSolid Queue، وصولاً إلى تصدير كود نظيف وتوثيق متكامل إلى مستودعات GitHub، مؤكداً أن اتفاقيات Rails العريقة تجعلها البيئة الأكثر مثالية للبرمجة الوكالية الحديثة.

## Atmosphere & style يتسم العرض بطابع عملي حماسي يمزج بين الفكاهة الذكية والعمق الهندسي الرصين؛ حيث يظهر المتحدث شغفاً حقيقياً بثقافة ومجتمع Ruby on Rails على مدار عقود. تبدأ الأجواء بنبرة نقدية طريفة تجاه طوفان أدوات JavaScript السريعة، لتتحول تدريجياً إلى شرح تقني معماري مشوق ومبهر يستعرض نماذج حية وتطبيقات واقعية بُنيت بالكامل عبر النظام. ينقل المتحدث شعوراً بالثقة والتفاؤل بمستقبل بيئة Rails، خاتماً كلمته بحماس ملهم يدعو الحضور لاستكشاف الأداة وبناء أفكارهم بأنفسهم.

## Bulletin - [03:16](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=196s) إطلاق منصة Hifumi مفتوحة المصدر (hifumi.dev) لتوليد تطبيقات ويب حية وكاملة مبنية على إطار Ruby on Rails بدلاً من بيئات JavaScript الشائعة في مولدات الأكواد الحالية. - [10:59](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=659s) تعتمد المنصة على سير عمل مهيكل تقوده أداة Roast المطورة من Shopify بالتكامل مع RubyLLM وClaude Code لتقسيم عملية التطوير إلى مراحل مراجعة (Revisions) دقيقة ومحكمة. - [15:24](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=924s) تنفيذ كل مرحلة بناء داخل حاوية Docker مؤقتة تُحذف فورياً (`--rm`)، مع تطبيق فحوصات حتمية واختبارات تكاملية حالت دون الحاجة للتراجع التلقائي للكود طوال ثلاثة أشهر من التجارب. - [17:30](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1050s) توفير نظام معاينة تفاعلية حية يربط بين Docker وKamal Proxy وفحص الجاهزية `/up`، مع بث الواجهة مباشرة للمستخدم داخل إطار iframe بالاعتماد على Solid Queue وHotwire.

## Key takeaways - [00:12](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=12s) معظم منصات الذكاء الاصطناعي التوليدية المتاحة تقيد المستخدمين بنظام JavaScript، مما يجعل رواد الأعمال غير التقنيين ملزمين بمسار تقني قد لا يناسب بناء تطبيقات ويب متكاملة مثلما يتيح Ruby on Rails. - [03:16](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=196s) اسم المشروع Hifumi مستوحى من طريقة العد اليابانية التقليدية للأرقام الثلاثة الأولى (Hi, Fu, Mi)، ويعمل المشروع كقالب مفتوح المصدر يتطلب فقط تزويد مفتاح OpenRouter الشخصي لتغطية استهلاك الرموز. - [05:22](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=322s) يبدأ بناء التطبيق باستيضاح المتطلبات وطرح أسئلة متابعة وتوليد بيانات تجريبية (Seed Data) لضمان ظهور التطبيق بواجهة واقعية فور التشغيل. - [05:22](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=322s) الاعتماد على خطة تنفيذ مرحلية مفصلة بدلاً من الموجهات الشاملة المباشرة يقلل من مخاطر البرمجة الوكالية التي قد تنتج سلوكيات غير مرغوبة للتعليمات غير المصرح بها. - [05:22](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=322s) تطبيق قاعدة محورية في توليد الواجهات تلزم الوكيل البرمجي بوضع الميزة الأساسية في مسار الجذر (Root Route) لتجنب فتح تطبيقات فارغة للمرة الأولى. - [10:59](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=659s) هيكلة كل خطوة في الخطة تحت مسمى 'مراجعة' (Revision) ذات نطاق مستقل، تنتج عند اكتمالها التزامين نظيفين في مستودع Git أحدهما للكود والآخر لملفات التوثيق. - [10:59](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=659s) استخدام لغة سير العمل Roast التابعة لشركة Shopify يفصل المسؤوليات بدقة بين الأوامر الحتمية والمهام المعتمدة على الذكاء الاصطناعي بدلاً من احتكار النموذج لكامل المنظومة. - [12:55](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=775s) تكامل مكتبة RubyLLM 2.0 لإدارة الاتصال بالنماذج مع أداة Claude Code التي تنفذ التعديلات في بيئة سطر الأوامر باستخدام وضع تجاوز الأذونات المستقل (`--dangerously-skip-permissions`). - [15:24](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=924s) تطبيق دورة تحقق مؤتمتة تعالج الأخطاء المتوقعة حتمياً أولاً (مثل تثبيت الحزم)، وتمنح الوكيل فرصة أو فرصتين للتصحيح الذاتي قبل إعلان فشل البناء. - [15:24](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=924s) عزل عمليات بناء المراجعات داخل حاويات Docker معزولة تعمل بخيار الإتلاف التلقائي (`--rm`) لتوفير طبقة حماية أمنية للخادم المضيف ضد الأكواد غير الموثوقة. - [17:30](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1050s) إدارة المعاينة الحية السحابية والمحلية عبر تسجيل الحاويات الجاهزة داخل Kamal Proxy فور اجتياز فحص السلامة المدمج في ريلز (`/up`). - [22:29](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1349s) إدارة المنظومة التشغيلية بالكامل بالاعتماد على خمس مهام خلفية فقط في Solid Queue مع بث الاستجابات والتحديثات اللحظية عبر Hotwire. - [22:29](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1349s) استخدام نمط النشر والاشتراك (Pub/Sub) عبر `ActiveSupport::Notifications` لفك الارتباط المباشر بين منطق البناء ومنطق إيقاف وإدارة حاويات المعاينة القديمة. - [22:29](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1349s) منح المستخدمين الملكية التامة للكود المصدري عبر ميزة التصدير المباشر بضغطة زر واحدة إلى مستودع GitHub خاص، شاملاً سجل الإيداعات والتوثيق. - [27:25](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1645s) اتفاقيات Rails الصارمة وعقلية الاختبارات المسبقة المتجذرة منذ عشرين عاماً تجعل الإطار الخيار الأكثر انسجاماً وتوافقاً مع فهم النماذج اللغوية في عصر الوكلاء البرمجيين.

## Detailed walkthrough ### [00:12](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=12s) خلفية الفكرة والحاجة إلى مولد تطبيقات خاص بـ Ruby on Rails

تبدأ جميع المواقع الإلكترونية بفكرة أو حلم؛ فقد يرغب طفل في إنشاء موقع يجعله ثرياً، أو يطلب "ديفيد" (ديفيد هاينماير هانسون) إنشاء مدونة تقتصر على المقالات والتعليقات، أو يبحث شخص مثل "بوب" عن تطبيق ويب داخلي مخصص للموارد البشرية داخل شركته. تتيح أدوات الذكاء الاصطناعي التوليدية والنماذج اللغوية الكبيرة (LLMs) اليوم تحويل هذه الرغبات إلى واقع بمجرد كتابة أمر نصي في منصات مثل Lovable أو v0 أو Bolt.new. تكمن المشكلة الجوهرية في أن معظم هذه المولدات تُنتج حصراً تطبيقات مبنية على لغة JavaScript، رغم أن إطار عمل Ruby on Rails لا يزال يمثل، في نظر الكثيرين، الخيار الأمثل لبناء تطبيقات الويب الحديثة والمتكاملة.

يقدم باويل ستراكوفسكي (Paweł Strzałkowski) نفسه وخلفيته المهنية؛ فهو يعمل نهاراً كمدير تقني (CTO) في وكالة البرمجيات البولندية Visuality المتخصصة في Ruby ومقرها وارسو، كما أنه شريك مؤسس في شركة الاستشارات Century Perspective التي تدعم تطبيقات Rails الناضجة للتكيف مع ثورة الذكاء الاصطناعي. ومع مرور 30 عاماً على بنائه أول موقع إلكتروني باستخدام لغة HTML البسيطة، يواصل باويل اليوم بناء تطبيقات تعتمد على الوكلاء الأذكياء (Agentic Coding) والنماذج اللغوية مستخدماً إطار Rails. يرى باويل أن أهمية المولدات تتضاعف عند مقارنة 30 مليون مطور يستخدمون الأدوات الذكية بالقاعدة الضخمة لمستخدمي الإنترنت البالغة 6 مليارات شخص لديهم جميعاً أفكار لمشاريع؛ فالمطالبة النصية الأولى التي يكتبها شخص غير تقني غالباً ما تقيده بالتقنية الناتجة وتحدد المسار التقني لشركته الناشئة بالكامل.

- تضم منصات المولدات الحالية أدوات شهيرة تُخرج شفرات برمجية تعتمد بالكامل على منظومة JavaScript. - يهدف المشروع إلى جلب قوة إطار Ruby on Rails إلى المستخدمين الذين يبنون التطبيقات بالكامل عبر مربعات الأوامر النصية. - كتابة تطبيقات الويب بواسطة Rails تفتح آفاقاً لتوسيع استخدام النماذج اللغوية الكبيرة وتعزز بيئة ومجتمع المطورين التابعين له.

---

[03:16](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=196s) تسمية المشروع وإطلاق منصة Hifumi

واجه المشروع تحدياً مبكراً كاد أن يوقفه وهو مرحلة التسمية؛ إذ سعى باويل في البداية إلى اسم مستوحى من مصطلحات القطارات والسكك الحديدية الشهيرة في بيئة Rails، مثل "Locomotive" أو "Depot"، لكنها لم تكن خيارات مقنعة. قاده التفكير للعودة إلى الأصول الثقافية اليابانية للغة Ruby، انطلاقاً من مبدأ أن بناء تطبيق ويب يجب أن يكون سهلاً وسلساً مثل العد "واحد، اثنان، ثلاثة". ورغم معرفته المحدودة باللغة اليابانية التي تقتصر على العد حتى 99، وجد أن النطق المباشر لأرقام "Ichi, Ni, San" يبدو ثقيلاً نوعاً ما وغير ملائم للاسم البرمجي المنشود.

لجأ باويل إلى استشارة Claude، الذي اقترح طريقة يابانية تقليدية في العد حتى الرقم عشرة وهي "Hi, Fu, Mi" (هي، فو، مي). إلى جانب دلالتها العددية، يُعد "Hifumi" اسماً شخصياً يابانياً مألوفاً، مما جعل الكلمة تترك أثراً فورياً لديه. نتج عن ذلك منصة Hifumi، وهو مشروع مفتوح المصدر يُعد بمثابة مخطط تطبيقي لإنشاء مشاريع Rails، والمتاح للجميع عبر الرابط المباشر `hifumi.dev`. المنصة مجانية ومفتوحة بالكامل، وتتطلب فقط إدخال مفتاح الـ API الخاص بالمستخدم من خدمة OpenRouter لتغطية تكاليف الرموز (Tokens)، مع إمكانية استنساخ المشروع وتشغيله محلياً دون أي قيود.

```mermaid flowchart LR accTitle: Hifumi App Lifecycle Overview accDescr: The lifecycle steps from an initial user idea to GitHub export and deployment. subgraph Flow["دورة حياة التطبيق في Hifumi"] Idea["الفكرة والمطالبة النصية"] --> Plan["استيضاح الفكرة وبناء الخطة"] Plan --> Build["التنفيذ عبر الوكلاء"] Build --> Preview["المعاينة والتحسين التكراري"] Preview --> Export["التصدير إلى GitHub"] end ```

- الاسم Hifumi مستمد من العد التقليدي الياباني للأرقام الثلاثة الأولى: "Hi" (واحد)، "Fu" (اثنان)، "Mi" (ثلاثة). - يعتمد الموقع المنشور hifumi.dev على تزويد المستخدم لمفتاح OpenRouter API لحسابه الخاص: "أنا لن أدفع تكاليف الرموز (Tokens) نيابة عنكم. لقد ولى ذلك الزمن". - يتيح سير العمل العام الانتقال من الفكرة، إلى البناء، والمعاينة الحية، والتحسين، وصولاً لتصدير الكود المصدري النهائي بالكامل إلى حساب GitHub تمهيداً للإطلاق التجاري والاكتتاب العام (IPO).

---

[05:22](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=322s) استيضاح المتطلبات وصياغة خطة التنفيذ متعددة المراحل

يبدأ العمل في Hifumi بطرح المتطلبات الوظيفية واحتياجات العمل في صندوق إدخال نصي بارز داخل لوحة التحكم، مع توفير خيارات لتحديد نماذج ذكاء اصطناعي مختلفة للمهام الفرعية عبر حزمة Ruby LLM. ولأن الأفكار الأولية تكون غير واضحة أو ناقصة بطبيعتها، يقوم Hifumi بدور الفريق الاستشاري عبر طرح أسئلة متابعة متتالية لتوضيح التفاصيل، مثل الاستفسار عما إذا كان التطبيق يحتاج لبيانات تجريبية أولية (Seed Data)، نظراً لأن التطبيق يبدو فارغاً وسيئاً بدونها، بينما "يتألق حقاً" عندما يتضمن بيانات حية توضيحية. وعند استقرار الرؤية، يسأل المساعد المستخدم: "هل أنت مستعد للبدء في البناء؟" ليشرع مباشرة في وضع خطة التنفيذ.

تعتمد المنهجية البرمجية على تقسيم الهدف إلى مراحل مدروسة؛ فالاعتماد على أمر وكيل مباشر مثل `slash golden clothes` لتنفيذ كل ما يطلبه المستخدم دفعة واحدة ينطوي على مخاطرة، لأنه "في البرمجة الوكالية (Agentic Coding)، أي شيء لا تقوله سيُستخدم ضدك بطريقة أو بأخرى". لمعالجة هذا، يولد Hifumi خطة تنفيذ مفصلة؛ فعند طلب تطبيق مدونة للمنشورات والتعليقات، صاغ النظام خطة من 5 خطوات شملت: إنشاء نماذج البيانات، ضبط التخطيط العام، توليد البيانات الأولية، وإجراء اختبار تكاملي شامل (System/Integration Test). لا تقتصر كل خطوة على مجرد ملخص عام، بل تتحول في الكواليس إلى موجه مفصل وكامل (Detailed Agentic Prompt) يمتد لصفحة كاملة من التعليمات الصارمة الموجهة للأداة البرمجية.

- يتيح Hifumi تخصيص نماذج لغوية متعددة للمهام المنفصلة أثناء الإعداد. - يُطرح سؤال محدد دائماً حول تضمين بيانات أولية لإعطاء الواجهة مظهراً حقيقياً فور التشغيل. - تضمنت تجربة تحويل المدونة لتصبح متمحورة حول مشروع أمارشي (Omarchy) خطة جديدة شملت: تغيير الهوية البصرية، وتعديل التنسيق والخطوط، وتحديث المحتوى، مع الحفاظ على هيكل التطبيق الأصلي. - قاعدة أساسية لتوليد تطبيقات الويب: "ضع الميزة الرئيسية في مسار الجذر (Root Route)"، لتجنب الحصول على تطبيق مبني بنجاح لكنه يعرض صفحة فارغة عند فتحه للمرة الأولى.

---

[10:59](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=659s) بنية خطة العمل ولغة النطاق واستخدام أداة Roast

تظهر واجهة متابعة البناء في Hifumi تحديثات حية لحالة الخطة؛ إذ تُميز كل مرحلة بحالات مرئية واضحة (مكتملة، قيد الإنشاء، أو معلقة) باستخدام تقنيات Hotwire وبث التنبيهات المباشرة عبر Active Support Notifications. وفي لغة النطاق (Domain Language) الخاصة بـ Hifumi، يُطلق على كل مرحلة من مراحل الخطة اسم "مراجعة" (Revision). تتكامل هذه المراجعات لتشكل الخطة العامة للمشروع، وتمتلك كل مراجعة هدفاً مستقلاً، وملخصاً من جملة واحدة، ونطاق عمل محدد المعالم تلتزم به بدقة.

```mermaid flowchart TD accTitle: Hifumi Revision Workflow Execution accDescr: Structure of a single Revision execution yielding deterministic steps and LLM actions into two git commits. subgraph PlanStructure["بنية الخطة والمراجعة (Revision)"] Rev["المراجعة (Revision)<br/>- هدف محدد<br/>- ملخص مركز<br/>- نطاق العمل"] end subgraph WorkflowEngine["سير العمل عبر Roast"] Steps["خطوات حتمية (Deterministic)<br/>+ مهام قائمة على LLM"] end subgraph Output["المخرجات في مستودع Git"] C1["التزام كود المصدر (Code Commit)"] C2["التزام التوثيق (Docs Commit)"] end Rev --> Steps Steps --> C1 Steps --> C2 ```

يتم تشغيل كل مراجعة من خلال "سير عمل" (Workflow) يتألف من سلسلة خطوات تجمع بين التنفيذ الحتمي للأوامر والمهام التي تتطلب تدخلاً من النماذج اللغوية. وعند اكتمال معالجة مراجعة معينة، يُسجل النظام تلقائياً التزامين منفصلين (Two Commits) في مستودع Git: أحدهما مخصص للتعديلات البرمجية التي طرأت على كود التطبيق، والآخر يوثق التغييرات في ملفات التوثيق. ويتم إدارة وهندسة سير العمل الداخلي بالكامل بالاعتماد على Roast، وهي لغة برمجية وسيطة مفتوحة المصدر طورتها Shopify وتعتمد على Ruby لتنفيذ مسارات العمل المعقدة التي تدمج التعديلات الحتمية مع التوجيهات الذكية. وقد فضّل باويل الاعتماد عليها لضمان فصل واضح للمسؤوليات داخل النظام بدلاً من احتكار Ruby LLM لكل مفاصل المشروع.

- تعتمد المتابعة الحية على Hotwire لبث تغيرات حالة المراحل من "قيد البناء" إلى "مكتمل". - تبدأ الخطة دائماً من هيكل قالب مسبق لتطبيق Rails (App Skeleton) ولا تبدأ من الصفر المطلق لضمان السرعة وتماسك الإعدادات. - تسفر كل مرحلة مكتملة عن حفظ التزامين نظيفين في Git (الكود المصدري + التوثيق). - تم اختيار Roast من Shopify خصيصاً لقدرتها العالية على الدمج المنظم بين العمليات الحتمية وعمليات الذكاء الاصطناعي مع إبقاء المعمارية مفصولة ومنظمة.

[12:55](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=775s) دور RubyLLM وRoast في إدارة سير العمل والربط مع Claude Code

يقوم المعمار الأساسي لـ Hifumi على الفصل التام بين طبقة التواصل مع النموذج اللغوي (LLM) وطبقة تنفيذ وإدارة سير العمل (Workflow). يمازح بافاو الحضور بأنه كان يود أن يسأل كم شخصاً في القاعة استخدم حزمة RubyLLM، لكنه لا يستطيع رؤيتهم بسبب أضواء المسرح، لذا يكتفي بتوجيه شكر خاص لمطورها Carmine Paolino، مؤكداً أنه "لولا RubyLLM لما وُجد هذا المشروع على الإطلاق"، ومشيراً إلى إطلاق الإصدار 2.0 مؤخراً. لتنظيم هذه الخطوات، يعتمد المشروع على أداتين متكاملتين: مكتبة RubyLLM لإدارة التفاعل اللغوي، وأداة Roast لإدارة مسارات العمل خطوة بخطوة.

```mermaid flowchart TD accTitle: دورة تنفيذ المراجعات في Hifumi accDescr: رسم توضيحي لمراحل بناء المراجعة، بدءاً من تجميع الأمر، والتنفيذ في حاوية دوكر، وصولاً إلى الفحص والتوجيه عبر كمال بروكسي. subgraph S_PREP ["1. إعداد الأمر وتوليد الكود"] A["تحديد مهام المراجعة ونطاق العمل"] --> B["إدراج التوثيق ولقطة مساحة العمل"] B --> C["تطبيق قواعد ريلز والاختبارات"] C --> D["إرسال الأمر إلى Claude Code"] end

subgraph S_EXEC ["2. التنفيذ والعزل في Docker"] D --> E["تشغيل حاوية معزولة مؤقتة (--rm)"] E --> F["فحص البناء: bundle و Sidekiq وطلبات GET"] F --> G{"هل تنجح الاختبارات؟"} G -- "نعم" --> H["حفظ التغييرات وتحديث التوثيق"] G -- "لا" --> I["إصلاح حتمي أو إعادة المحاولة عبر الوكيل"] I --> G end

subgraph S_SERVE ["3. النشر والمعاينة الحية"] H --> J["فحص سلامة التطبيق (/up)"] J --> K["تسجيل المسار في Kamal Proxy"] K --> L["بث المعاينة عبر Solid Queue و Hotwire"] end ```

يتبع سير عمل Roast مجموعة محددة من المراحل تُنفذ مع كل "مراجعة" (Revision) أو مرحلة من الخطة. تبدأ العملية ببناء موجه الأوامر (Prompt)، والذي يجمع مهام المراجعة المحددة، ونطاق العمل المطلوب، والتوثيق المكتوب للمشروع حتى تلك اللحظة، بالإضافة إلى لقطة شاملة (Snapshot) لحالة مساحة العمل الحالية. كما تُحقن مع الموجه قواعد عمل صارمة تضمن الجودة؛ مثل الالتزام بفلسفة ريلز التقليدية ("Do it the Rails way") وتغطية الشيفرة البرمجية بالاختبارات الشاملة. فور اكتمال الأمر، يُمرر إلى Claude Code — وهو الأداة المفضلة لدى بافاو، مع إمكانية استبدالها بنماذج أخرى عبر مهايئات متوافقة مع Claude أو من خلال مفتاح OpenRouter API. يتم تشغيل الوكيل باستخدام خياره المفضل: تجاوز الأذونات التلقائي (`--dangerously-skip-permissions`)، لتفادي مقاطعة المستخدم بطلبات الموافقة اليدوية في كل تعديل.

تتميز هذه البنية بميزة اقتصادية وعملية هائلة؛ إذ إن تشغيل Hifumi محلياً (Localhost) يعتبر مجانياً بالكامل لمن يمتلك اشتراكاً في Claude، مما يتيح تجربة النظام وتوليد التطبيقات والتوثيق دون دفع فلس واحد لتوليد الشيفرة. أما المحادثات التمهيدية المدارة عبر RubyLLM ونموذج OpenRouter فلا تكلف سوى بضعة سنتات زهيدة.

- **RubyLLM 2.0**: الحزمة الأساسية للاتصال بالنماذج الذكية، ومحرك التوليد النصي التفاعلي. - **Roast**: محرك إدارة خطوات العمل المتسلسلة لكل مرحلة بناء. - **Claude Code**: أداة تنفيذ وتعديل الأكواد الفعلية عبر واجهة سطر الأوامر. - **`--dangerously-skip-permissions`**: علم تشغيل أساسي يمنح الوكيل البرمجي صلاحية العمل التلقائي المستقل دون مقاطعة المستخدم.

---

[15:24](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=924s) دورة التحقق، الإصلاح الحتمي، والعزل عبر حاويات Docker

بمجرد أن ينتهي الوكيل من كتابة الشيفرة للمراجعة المحددة، تبدأ مرحلة الفحص الآلي الصارم للتأكد من سلامة التطبيق. تشمل هذه الفحوصات التأكد من تثبيت الحزم بنجاح عبر `bundle install`، واجتياز فحوصات العمليات الخلفية (مثل Sidekiq)، وإجراء اختبارات على جميع مسارات GET للتأكد من عدم ظهور أي أخطاء برمجية في الصفحات، ثم تشغيل حزمة الاختبارات المؤتمتة الكاملة داخل بيئة Hifumi. في حال وجود أخطاء، يسعى النظام لحلها أولاً بطريقة "حتمية" (Deterministic)؛ فإذا نسي الوكيل تثبيت حزمة جديدة، يقوم النظام بتشغيل أمر التثبيت تلقائياً. أما إذا كان الخطأ يتطلب تدخلاً منطقياً، يُرسل النظام أمر إصلاح موجه للوكيل لمحاولة تصحيح الخطأ مرة أو مرتين.

وفي سيناريو الفشل المستمر الذي يعجز الوكيل عن معالجته، يُصنف بناء المراجعة كبناء فاشل، ويتم التراجع تلقائياً في مستودع Git إلى الحالة السابقة لتلك المراجعة. ويشير بافاو بفخر إلى أن آلية التراجع هذه لم تُستدعَ مطلقاً طوال الأشهر الثلاثة الأخيرة من الاختبارات في Hifumi بفضل دقة الإصلاح الذاتي. وعند اجتياز كافة الفحوصات بنجاح، تُحفظ التغييرات في Git، ويُولد توثيق تقني للمرحلة ويُحفظ بالتوازي، لتكتمل الخطة خطوة بخطوة.

أما عن الجانب الأمني، فإن إعطاء نموذج ذكاء اصطناعي صلاحيات كتابة وتشغيل أكواد بأذونات غير مقيدة مباشرة على الخادم المضيف يمثل خطورة بالغة. لحل هذه المعضلة، تنشئ كل مراجعة حاوية Docker مؤقتة ومستقلة تماماً، تُشغل مع خيار الحذف الفوري (`docker run --rm`)، بحيث تُدمر الحاوية بالكامل فور انتهاء المراجعة. ومع أن حاويات دوكر لا توفر عزلاً أمنياً تاماً كالأجهزة الوهمية، إلا أنها تضمن فصلاً آمناً بين مراجعات العمليات البرمجية وبيئة الخادم الأساسية.

- **فحوصات السلامة الآلية**: فحص سلامة الحزم (`bundle`)، وتكامل Sidekiq، والتأكد من استجابة جميع مسارات طلبات HTTP GET دون انهيار. - **استراتيجية الإصلاح ثنائية المسار**: إصلاحات حتمية تلقائية للأخطاء المتوقعة، تليها مطالبات تصحيح يحللها الوكيل الذكي (محاولة إلى محاولتين). - **العزل التشغيلي**: تنفيذ كل مراجعة وكل تطبيق Rails داخل حاوية Docker مؤقتة باستخدام الخيار `--rm`.

---

[17:30](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1050s) نظام المعاينة الحية: Docker وKamal Proxy وSolid Queue

يصف بافاو ميزة المعاينة الحية بأنها "الجزء الأكثر متعة" في المعمار التقني بأكمله؛ فالمعضلة الهندسية تكمن في: كيف يمكن لتطبيق Rails قيد التشغيل أن ينشئ ويعاين تطبيق Rails آخر بالكامل ومنحه واجهة حية تفاعلية؟ يقدم بافاو عرضاً حياً لتطبيق بُني من الصفر بمطالبة خالية تماماً من أي مصطلحات تقنية أو ذكر لإطار ريلز، وتقتصر على متطلبات العمل الفعلية. وبمجرد اكتمال البناء، تظهر نافذة المعاينة الحية داخل إطار `iframe` متكامل.

يستعرض بافاو التطبيق الناتج، وهو عبارة عن منصة مجتمعية لتنظيم رحلات المشي لمسافات طويلة (Hiking). يمكن للمستخدم تسجيل حساب جديد، وتصفح الرحلات المتاحة؛ حيث يعرض رحلة في إنجلترا يشارك فيها شخصان فقط، ثم يضغط على زر الانضمام، ليتغير طلبه فوراً إلى "معلق" (Pending) داخل صفحة الحساب الشخصي. يعلق بافاو بابتسامة: "قد لا يبدو الأمر فائق التعقيد، لكنه تطبيق Rails تفاعلي متكامل، مكتمل الوظائف وذو مظهر جميل جداً".

تعتمد البنية التحتية لهذه المعاينة على الدمج بين Docker وKamal Proxy. تبدأ الخطوات ببناء صورة دوكر للتطبيق المُولد ثم تشغيل الحاوية. في بيئة التطوير المحلية (Localhost)، تُربط الحاوية بمنفذ ديناميكي يعتمد على معرف المشروع (المنفذ 3000 مضافاً إليه معرف المشروع، مثل المنفذ `3010`). أما في بيئة الإنتاج السحابية، تُربط الحاوية بنطاق فرعي مثل `project_id.preview.hifumi.dev`. يقوم النظام بعد ذلك بالتحقق من جاهزية التطبيق عبر طلب `curl` موجه إلى نقطة الفحص الافتراضية في ريلز (`/up`). وبمجرد نجاح الفحص، يُنفذ أمر سطر أوامر عبر دوكر لربط التطبيق مع Kamal Proxy: `docker exec kamal-proxy...` ليصبح التطبيق متاحاً للإنترنت الخارجي فوراً. وبفضل إدارة هذه التدفقات بالكامل عبر مهمة خلفية في Solid Queue، يتم بث جاهزية الرابط مباشرة إلى واجهة المستخدم عبر Hotwire لتظهر داخل الـ `iframe` دون الحاجة إلى تحديث الصفحة.

- **منفذ المعاينة المحلي**: `localhost:3000 + project_id` (مثال: `localhost:3010`). - **نطاق الإنتاج الفرعي**: `project_id.preview.hifumi.dev` مسجل وموجه عبر Kamal Proxy. - **فحص الجاهزية**: الاعتماد على مسار Rails المدمج `/up` قبل توجيه الزوار. - **التحديث المباشر**: استخدام Solid Queue لمعالجة الإعداد، وبث كود الـ `iframe` للعميل عبر تقنيات Hotwire.

---

[22:29](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1349s) بنية الأحداث (Pub/Sub) والتصدير السلس إلى GitHub مع أمثلة للتطبيقات

على الرغم من العمليات الحسابية والمعمارية المعقدة التي يديرها Hifumi، فإن التطبيق بأكمله يعتمد على خمس مهام خلفية فقط (Jobs) داخل Solid Queue. حتى رسائل الدردشة الموجهة للنموذج اللغوي تُحال إلى مهمة خلفية، وتُسلّم كافة الإجراءات والردود عبر Hotwire في الوقت الفعلي. لتحقيق أقصى درجات الفصل بين المكونات، استعان بافاو بنمط الناشر والمشترك (Pub-Sub) المدمج في ريلز عبر `ActiveSupport::Notifications`.

يربط نمط الأحداث بين أجزاء النظام بسلاسة دون وجود اعتماديات مباشرة بين منطق البناء ومنطق المعاينة؛ فعلى سبيل المثال، عند طلب خطة بناء جديدة، يُطلق النظام حدثاً باسم `instruction_requested`. يشترك نظام المعاينة في هذا الحدث، وبمجرد التقاطه، يقوم بجدولة مهمة لإيقاف وإغلاق أي حاوية معاينة تعمل حالياً لهذا المشروع، مما يضمن تحرير الموارد وعدم تضارب الإصدارات القديمة مع عمليات البناء الجارية.

``` [طلب خطة جديدة: instruction_requested] │ ▼ (ActiveSupport::Notifications) [مشترك إدارة المعاينة] │ ▼ [جدولة مهمة Solid Queue لإيقاف حاوية المعاينة السابقة] ```

يؤكد بافاو أن ملكية المشروع تعود بالكامل للمستخدم وليس لـ Hifumi. يتيح النظام تصدير الكود إلى مستودع GitHub خاص بالمستخدم في أي لحظة وبنقرة زر واحدة. تُسجل كل مراجعة تم بناؤها في سجل التغييرات على هيئة إيداعين منفصلين (Two Git Commits)، ويمكن للمستخدم متابعة البناء لاحقاً باستخدام Hifumi ودفع الإيداعات الجديدة إلى المستودع تباعاً.

عند استعراض الكود المصدري المُصدَّر لتطبيق اللياقة البدنية، تظهر وحدات التحكم (Controllers) نظيفة ومنسقة؛ حيث تبدو `WorkoutsController` كوحدة تحكم ريلز قياسية وبسيطة، بينما تحتوي `CalendarsController` على منطق أعمال مجالي أكثر عمقاً. يختتم بافاو هذا الجزء باستعراض تنوع المشاريع التي أُنشئت بنجاح عبر Hifumi بالكامل من خلال Ruby on Rails: - **صفحة هبوط لصالة ألعاب رياضية (Gym Landing Page)**: واجهة تسويقية جذابة خالية من التعقيدات البرمجية. - **بوابة تصميم داخلي (Interior Design Portal)**: تتضمن مساعد تصميم تفاعلي لتحديد الغرف، والأثاث، والميزانية. - **منصة اجتماعية للرحلات الخلوية (Hiking Social Network)**: تتيح استكشاف الرحلات وتنظيم الانضمام إليها. - **شبكة تواصل عائلية**: لمشاركة اللحظات والصور الخاصة بين أفراد العائلة. - **نظام إدارة موارد بشرية (HR App)**: لإدارة إجازات الموظفين، وأوقات العمل، والجداول الزمنية داخل الوكالات. - **مخطط جداول المؤتمرات (Conference Agenda Planner)**: لإضافة المؤتمرات، وجداول المتحدثين، ونشر رابط عام للمشاركين. - **نظام إدارة أساطيل المركبات (Fleet Manager)**: تطبيق B2B متقدم يتيح تتبع استهلاك الوقود، والتقارير، وإدارة السائقين والمركبات.

[27:25](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1645s) قوة Rails في عصر الوكلاء الذكيين ودعوة لتجربة Hifumi

يختتم المتحدث عرضه بتسليط الضوء على الإمكانات الهائلة الكامنة في إطار عمل Rails، مشيراً إلى أن ما تم بناؤه سواء استُخدم مباشرة كدفعة واحدة أو مع إدخال بعض التعديلات الطفيفة لاحقاً، يجسد القوة الحقيقية التي اكتسبها المجتمع التقني على مدار ما يقارب العشرين عاماً الماضية. هذه القوة تنبع من التقاليد والاتفاقيات الراسخة (Conventions) وعقلية "الاختبار أولاً" (Test-first mindset)، إضافة إلى كافة الأدوات المتكاملة والمتاحة فوراً للاستخدام الجاهز داخل بيئة Rails. الميزة الجوهرية هنا تكمن في أن النماذج اللغوية الكبيرة (LLMs) باتت تفهم هذه الاتفاقيات الصارمة بشكل أفضل وأدق يوماً بعد يوم، مما يجعل التوافق بين الإطار والذكاء الاصطناعي طبيعياً وسلساً.

يوضح المتحدث أنه عند دمج خطة عمل محكمة وتقسيم مدروس للمهام إلى أجزاء ومراحل واضحة، مع إجراء مراجعات دقيقة لكل خطوة، يصبح بالإمكان استغلال هذا النهج التقني بنجاح في العمل البرمجي اليومي، سواء بالاعتماد على أداة Hifumi نفسها أو بتطبيق المنهجية بشكل مستقل داخل أي بيئة تطوير. ويختم حديثه بنبرة حماسية داعياً الحضور والمهتمين إلى زيارة موقع `hifumi.dev`، وتجربة الأداة بأنفسهم، والأهم من ذلك استنساخ المستودع (Fork/Clone) وتشغيله محلياً، والاستمتاع بمواصلة البناء والتطوير باستخدام Ruby on Rails، معبراً عن إيمانه القاطع بقوله: "لأنني أعتقد حقاً أن روبي أون ريلز مهيأة تماماً لعصر الوكلاء الذكيين"، قبل أن يوجه شكره الجزيل للجمهور.

```mermaid flowchart LR accTitle: Rails and AI Agents Synergy accDescr: يوضح المخطط كيف تتكامل اتفاقيات ريلز وثقافة الاختبار مع نماذج الذكاء الاصطناعي لإنتاج تطبيقات متكاملة. subgraph RailsStrengths["ركائز Rails (20 عاماً)"] A["اتفاقيات واضحة وموحدة"] B["عقلية الاختبار أولاً"] end subgraph Execution["منظومة الوكلاء الذكيين"] C["فهم دقيق لدى نماذج LLM"] D["تخطيط وتجزئة مرحلية"] end subgraph Outcome["المخرجات"] E["تطبيقات منتجة عبر Hifumi"] end A --> C B --> C C --> D D --> E ```

- **تاريخ طويل من الاتفاقيات:** الاستفادة من خبرات وتراكمات تقنية دامت قرابة 20 عاماً تقدم حلولاً جاهزة ومجربة داخل إطار العمل دون الحاجة لإعادة اختراع العجلة. - **تناغم النماذج مع الاتفاقيات:** تبرع النماذج اللغوية الكبيرة (LLMs) في كتابة أكواد Rails وتتبع بنيتها بفضل وضوح المعايير وثبات الهيكلية عبر المشاريع. - **عناصر النجاح البرمجي بالأدوات الذكية:** يعتمد التطوير الفعال على خطة جيدة، وتجزئة المهام لمراحل محددة، ومراجعة مستمرة للتنفيذ. - **الدعوة لتجربة Hifumi والمساهمة مفتوحة المصدر:** حث المطورين على الدخول إلى `hifumi.dev`، وتجربة المنصة، وعمل Fork للكود البرمجي للمساهمة في تطويره والبناء بواسطته.

## Notable quotes > [03:16](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=196s) أنا لن أدفع تكاليف الرموز (Tokens) نيابة عنكم. لقد ولى ذلك الزمن — Paweł Strzałkowski

> [05:22](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=322s) هل أنت مستعد للبدء في البناء؟ — Paweł Strzałkowski

> [05:22](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=322s) في البرمجة الوكالية (Agentic Coding)، أي شيء لا تقوله سيُستخدم ضدك بطريقة أو بأخرى — Paweł Strzałkowski

> [05:22](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=322s) ضع الميزة الرئيسية في مسار الجذر (Root Route) — Paweł Strzałkowski

> [12:55](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=775s) لولا RubyLLM لما وُجد هذا المشروع على الإطلاق — Paweł Strzałkowski

> [12:55](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=775s) Do it the Rails way — Paweł Strzałkowski

> [17:30](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1050s) الجزء الأكثر متعة — Paweł Strzałkowski

> [17:30](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1050s) قد لا يبدو الأمر فائق التعقيد، لكنه تطبيق Rails تفاعلي متكامل، مكتمل الوظائف وذو مظهر جميل جداً — Paweł Strzałkowski

> [27:25](https://www.youtube.com/watch?v=0_ZLKWlc7FY&t=1645s) لأنني أعتقد حقاً أن روبي أون ريلز مهيأة تماماً لعصر الوكلاء الذكيين — Paweł Strzałkowski

## Mentioned Paweł Strzałkowski, David Heinemeier Hansson, Carmine Paolino, Ruby on Rails, Hifumi, Roast, RubyLLM, Claude Code, Claude, Docker, Kamal Proxy, Solid Queue, Hotwire, ActiveSupport::Notifications, OpenRouter, GitHub, Shopify, Visuality, Century Perspective, Sidekiq, Lovable, v0, Bolt.new

## Video description Most AI app generators turn a prompt into a JavaScript app. Hifumi, an open-source generator, turns it into a working Ruby on Rails app instead. This talk walks through the full flow, from asking follow-up questions and writing a phased implementation plan to building each phase with Roast and Claude Code in throwaway Docker containers. It then covers live previews with Kamal Proxy and exporting the finished app to your own GitHub.

Links: https://hifumi.dev/

#RailsWorld #RubyOnRails #AI #RubyLLM #AgenticCoding #OpenSource Thank you Shopify for sponsoring the editing and post-production of these videos. Check out insights from the Engineering team at: https://shopify.engineering/

[Source](https://www.youtube.com/watch?v=0_ZLKWlc7FY)

中文简报

斯特拉科夫斯基发布 Hifumi：利用智能体构建完整 Rails 应用 Rails 框架历经20年的约定与测试先行文化，使其相较于主流 JavaScript 生态成为最适合自主编程的环境。帕维尔·斯特拉科夫斯基（Paweł Strąkowski）展示了 Hifumi 平台，旨在打破 JavaScript 生态在 AI 代码生成器中的主导地位，将 Ruby on Rails 框架的优势带给用户和开发者。演讲介绍了如何将初步构想转化为多阶段执行计划，通过 Roast 和 RubyLLM 进行管理，并在隔离的临时 Docker 容器中通过 Claude Code 编程执行。内容还涉及自检架构、基于 Kamal Proxy 和 Solid Queue 的实时预览系统，以及将整洁代码和完整文档导出至 GitHub 仓库的全过程，并强调 Rails 悠久的约定使其成为现代智能体编程的理想环境。开源平台 Hifumi (hifumi.dev) 正式发布，用于生成基于 Ruby on Rails 框架的完整可运行 Web 应用，替代当前代码生成器中常见的 JavaScript 环境。 (3:16) 该平台依托 Shopify 开发的 Roast 工具所驱动的结构化工作流，结合 RubyLLM 和 Claude Code，将开发过程划分为精准严谨的版本迭代（Revisions）阶段。 (10:59) 每个构建阶段均在即时销毁（`--rm`）的临时 Docker 容器中执行，配合确定性检查和集成测试，在长达三个月的测试中避免了自动回滚代码的需求。 (15:24) 提供实时交互预览系统，打通 Docker、Kamal Proxy 与就绪检查（`/up`），依托 Solid Queue 和 Hotwire 在 iframe 中向用户实时推流应用界面。 (17:30)

Reading summary

يقدم باويل ستراكوفسكي مشروع Hifumi كمنصة مفتوحة المصدر لتوليد تطبيقات الويب عبر Ruby on Rails انطلاقاً من أوامر نصية، مؤكداً أن اتفاقيات الإطار الصارمة تجعله أكثر توافقاً مع أدوات الذكاء الاصطناعي التوليدي والوكلاء الأذكياء مقارنة بحلول JavaScript السائدة. معالجة احتكار منظومة JavaScript وإطلاق Hifumi (0:12) يوضح ستراكوفسكي أن منصات التوليد الشهيرة مثل Lovable وv0 وBolt.new تقصر مخرجاتها البرمجية على بيئة JavaScript، ما يفرض مساراً تقنياً مبكراً على أصحاب المشاريع غير التقنيين بمجرد صياغة أول طلب نصي. واستجابة لذلك، أسس مشروع Hifumi المتاح مجاناً عبر الرابط hifumi.dev، والذي يستند اسمه إلى طريقة العد اليابانية التقليدية (واحد، اثنان، ثلاثة)، بهدف جلب إمكانات Ruby on Rails الكاملة لمستخدمي أدوات التوليد. تعتمد المنصة على تزويد المستخدمين بمفاتيح API الخاصة بهم عبر خدمة OpenRouter لتغطية كلفة استهلاك الرموز، وتبدأ عمليات التوليد دائماً من قالب مسبق لهيكل التطبيق بدلاً من الصفر، مع تطبيق قاعدة تصميمية تلزم النظام بوضع الميزة الأساسية في مسار الجذر لضمان ظهور واجهة فعالة فور التشغيل. تفكيك المهام وإدارة سير العمل عبر Roast (5:22) يتفادى Hifumi تنفيذ الأوامر دفعة واحدة لما ينطوي عليه ذلك من أخطاء في البرمجة الوكالية، ويبدأ بدلاً من ذلك بحوار استيضاحي يتضمن أسئلة متابعة متتالية، مثل إضافة بيانات تجريبية أولية لضمان واقعية الواجهة. وعقب اكتمال المتطلبات، يُنشئ النظام خطة عمل مجزأة تتألف من خطوات يُطلق عليها في لغة نطاق المشروع اسم "مراجعات" (Revisions)، تحظى كل منها بنطاق محدد وموجّه نصي تفصيلي ومستقل. تُدار دورة حياة المراجعات باستخدام أداة Roast المفتوحة المصدر والمطورة من Shopify بالتكامل مع مكتبة RubyLLM 2.0؛ حيث تفصل Roast بين الخطوات الإجرائية الحتمية وتوجيهات النماذج اللغوية، وتسفر كل مراجعة مكتملة عن حفظ التزامين نظيفين في مستودع Git أحدهما للتعديل البرمجي والآخر لتوثيق التغييرات الفنية. العزل في الحاويات ودورة التحقق والإصلاح التلقائي (15:24) تُنفذ التعديلات البرمجية عملياً عبر أداة Claude Code مع تفعيل خيار تجاوز الأذونات، داخل حاويات Docker معزولة ومؤقتة تُحذف فور انتهاء المهمة لضمان أمان بيئة الخادم. وفور انتهاء الوكيل من كتابة الشيفرة، يُخضع Hifumi التطبيق لفحوصات آلية تغطي تثبيت الحزم، وتكامل مهام Sidekiq، وتجربة استجابة كافة مسارات GET، بالإضافة إلى تشغيل حزمة الاختبارات الكاملة. يعتمد النظام استراتيجية معالجة ثنائية تبدأ بمحاولة حل الأخطاء البسيطة حتمياً وبشكل تلقائي، وتمرير الأخطاء المنطقية للوكيل في محاولة أو محاولتين للإصلاح، مع توفير خيار للتراجع التلقائي في Git إذا فشل البناء؛ وهي ميزة ذكر ستراكوفسكي أنها لم تُستدعَ طوال ثلاثة أشهر من الاختبار بفضل كفاءة التصحيح الذاتي. المعاينة التفاعلية وبنية الأحداث وتصدير المشاريع (17:30) يتيح Hifumi فحص التطبيق المُنشأ مباشرة عبر إطار متصفح تفاعلي بالدمج بين Docker وKamal Proxy، حيث يُربط المشروع بمنافذ محلية ديناميكية أو بنطاقات فرعية سحابية، وتُفحص جاهزيته عبر نقطة التحقق المدمجة في ريلز (/up). وتدار هذه العمليات عبر بنية أحداث تعتمد على خمس مهام في Solid Queue ونمط النشر والاشتراك في Active Support Notifications، ما يتيح إيقاف الحاويات السابقة تلقائياً وبث الروابط للواجهة بواسطة Hotwire دون الحاجة لتحديث الصفحة. تظل ملكية الشيفرة بالكامل للمستخدم مع إمكانية تصديرها بنقرة زر إلى مستودع GitHub بسجل التزامات مرتب؛ وقد شملت النماذج الناجحة المبنية عبر المنصة شبكة اجتماعية لتنظيم رحلات المشي، ونظاماً للموارد البشرية، وتطبيقاً لتخطيط جداول المؤتمرات، ونظاماً متقدماً لإدارة أساطيل المركبات. يرى ستراكوفسكي أن التقاليد الهيكلية الصارمة المتراكمة في Rails على مدى نحو عشرين عاماً وعقلية "الاختبار أولاً" تجعل الإطار متناغماً بصورة استثنائية مع فهم النماذج اللغوية الكبيرة، داعياً المجتمع البرمجي إلى استنساخ Hifumi محلياً وتطبيق منهجية التخطيط المرحلي لبناء التطبيقات التوليدية.

Source quotes

[3:16] Paweł Strzałkowski: أنا لن أدفع تكاليف الرموز (Tokens) نيابة عنكم. لقد ولى ذلك الزمن [5:22] Paweł Strzałkowski: هل أنت مستعد للبدء في البناء؟ [5:22] Paweł Strzałkowski: في البرمجة الوكالية (Agentic Coding)، أي شيء لا تقوله سيُستخدم ضدك بطريقة أو بأخرى [5:22] Paweł Strzałkowski: ضع الميزة الرئيسية في مسار الجذر (Root Route) [12:55] Paweł Strzałkowski: لولا RubyLLM لما وُجد هذا المشروع على الإطلاق [12:55] Paweł Strzałkowski: Do it the Rails way [17:30] Paweł Strzałkowski: الجزء الأكثر متعة [17:30] Paweł Strzałkowski: قد لا يبدو الأمر فائق التعقيد، لكنه تطبيق Rails تفاعلي متكامل، مكتمل الوظائف وذو مظهر جميل جداً [27:25] Paweł Strzałkowski: لأنني أعتقد حقاً أن روبي أون ريلز مهيأة تماماً لعصر الوكلاء الذكيين

Original transcript

[0:12] كل موقع إلكتروني يبدأ [0:14] بحلم. ابني يقول إنه [0:17] يريد موقعاً يجعله [0:19] ثرياً فحسب. لكن شخصاً [0:21] مشهوراً يدعى ديفيد [0:23] قال ذات مرة إنه يريد [0:24] مدونة بها منشورات [0:26] وتعليقات، وها نحن ذا. [0:28] لدي أيضاً صديق يدعى [0:30] بوب يود حقاً الحصول [0:31] على تطبيق ويب داخلي [0:33] للموارد البشرية [0:35] لشركته. يمكنهم جميعاً [0:39] الآن تحقيق أحلامهم. [0:41] هناك عالم كامل من [0:42] مولدات التطبيقات [0:43] القائمة على النماذج [0:45] اللغوية الكبيرة. تذهب [0:46] إلى هناك، وتضع فكرتك [0:48] في مربع الأوامر، وها [0:50] هي جاهزة. تنتقل إلى [0:51] موقع "لوفابل" أو "بولت" [0:53] الجديد وتملأ هذا [0:55] الأمر فقط. هناك مشكلة [0:57] واحدة فقط. كل هذه [0:59] التطبيقات وتلك [1:01] المواقع تنتج إصداراً [1:02] ما من لغة جافا سكريبت. [1:06] لكن الأمر لا يجب أن [1:08] يكون هكذا. على حد علمي [1:10] ، لا يزال "روبي أون [1:11] ريلز" أفضل إطار عمل [1:13] لبناء تطبيق ويب. لذا، [1:16] ومن أجل جلب "روبي أون [1:18] ريلز" للأشخاص الذين [1:19] يبنون باستخدام [1:21] مربعات الأوامر فقط، [1:22] سأحدثكم اليوم عن " [1:24] هيفومي"، مولد تطبيقات [1:26] "ريلز" الخاص بي على [1:27] الإنترنت. مرحباً. أنا [1:30] باويل ستراكوفسكي. [1:31] أعمل نهاراً كمدير [1:33] تقني في شركة " [1:33] فيرتشواليتي"، وهي [1:34] وكالة "روبي" من وارسو [1:36] في بولندا. أنا أيضاً [1:37] عضو مؤسس في "سنتشري [1:39] بيرسبيكتيف"، وهي شركة [1:40] استشارية تساعد [1:41] منتجات "ريلز" الناضجة [1:43] في التحول في عصر [1:44] الذكاء الاصطناعي. [1:46] يصادف هذا العام [1:47] الذكرى الثلاثين [1:48] لبنائي أول موقع [1:50] إلكتروني لي. في ذلك [1:51] الوقت، كان الأمر [1:52] يقتصر على لغة "إتش تي [1:53] إم إل" فقط. اليوم أقوم [1:55] بإنشاء نماذج أولية [1:56] للمستقلين. وأدرس [1:57] البرمجة المعتمدة على [1:58] الوكلاء الأذكياء. [1:59] وأبني تطبيقات ومواقع [2:00] إلكترونية تعتمد على [2:02] النماذج اللغوية [2:02] الكبيرة. كل ذلك لا [2:04] يزال باستخدام "روبي [2:05] أون ريلز". إذا أردتم [2:06] التحدث عن أي من هذا، [2:08] يرجى العثور عليّ على " [2:09] جيت هاب" أو "لينكد إن" [2:11] أو في الردهة لاحقاً. [2:14] قد تسأل نفسك لماذا [2:16] تعد مولدات الويب مهمة [2:18] ولماذا هي موجودة [2:19] أصلاً. لأننا عندما [2:21] ننظر حولنا، نجد [2:23] بالفعل حوالي 30 مليون [2:25] شخص يستخدمون أدوات [2:27] التطوير الذكية. ومع [2:30] ذلك، هناك 6 مليارات [2:31] شخص يستخدمون [2:33] الإنترنت ولديهم [2:34] جميعاً أفكار وأحلام. [2:38] ولكن بما أن هناك [2:40] بالفعل العديد من [2:41] المولدات عبر [2:42] الإنترنت، فلماذا [2:44] نهتم بإدخال "ريلز" [2:45] إليها؟ ببساطة، مربع [2:48] الأوامر الذي يستخدمه [2:49] الأشخاص غير التقنيين [2:51] يحدد مسار شركاتهم [2:53] الناشئة القادمة. [2:54] وأياً كانت التقنية [2:56] التي ينتجها مربع [2:58] الأوامر هذا، [2:59] فستلازمهم طوال جزء [3:01] كبير من رحلتهم. بشكل [3:04] عام، البناء باستخدام [3:06] "ريلز" يزيد من وعي [3:08] الناس بالنماذج [3:09] اللغوية الكبيرة، [3:11] ويثري نظامنا البيئي. [3:16] نعم، لذا انطلقت في [3:18] هذه الرحلة لبناء مولد [3:20] "روبي أون ريلز". حسناً [3:24] ، هنا كاد المشروع أن [3:25] يفشل. بدأت بالبحث عن [3:29] اسم يحمل طابع "ريلز"، [3:31] مثل "لوكوموتيف" ربما. [3:33] كان أفضل خياراتي هو " [3:35] ديبو"، لكنني لم أُعجب [3:37] به كثيراً. بدأت [3:39] التفكير في العودة إلى [3:41] الجذور اليابانية [3:43] للغة روبي، وفكرت [3:45] أيضاً أن بناء [3:46] التطبيقات يجب أن يكون [3:48] سهلاً وبسيطاً كعدّ [3:50] واحد، اثنان، ثلاثة. [3:52] لحسن الحظ، أستطيع [3:53] التحدث ببعض [3:54] اليابانية. حسناً، [3:55] يمكنني العد حتى 99 [3:57] وهذا كل شيء. لذا فكرت، [3:58] 1، 2، 3، ماذا عن "إيتشي، [4:00] ني، سان"؟ لكن النطق [4:02] كان ثقيلاً بعض الشيء. [4:03] لم أشعر أن الأمر [4:04] مناسب حقاً. لذا تحدثت [4:06] كثيراً مع صديقي، ربما [4:07] تعرفونه، كلود. وقال [4:09] إن هناك طريقة أخرى، [4:11] طريقة تقليدية أكثر في [4:13] اليابانية، على الأقل [4:15] في العد حتى عشرة. وهي " [4:17] هي، فو، مي". في الواقع [4:20] ، "هي-فو-مي" هو أيضاً [4:22] اسم شخصي. لذا، كانت [4:24] كلمة لامست شيئاً في [4:25] داخلي حقاً. وها هي، " [4:27] هي-فو-مي"(Hi-fu-mi). إنه [4:30] مخطط مفتوح المصدر [4:31] لمنشئ تطبيقات "ريدز". [4:33] وهو يعمل بالفعل [4:34] حالياً على الرابط [4:36] hifumi.dev. يمكنكم زيارة [4:37] الموقع وبناء تطبيقكم [4:39] الأول. شيء واحد فقط، [4:40] التسجيل يتطلب مفتاح [4:42] API الخاص بـ Open Router. أنا [4:43] لن أدفع تكاليف الرموز [4:45] (Tokens) نيابة عنكم. لقد [4:46] ولى ذلك الزمن. لكن لا [4:48] يزال بإمكانكم زيارة [4:49] الموقع. إنه مفتوح [4:51] المصدر، لذا يمكنكم [4:52] استنساخه، وتشغيله [4:53] محلياً، وبناء أي شيء [4:55] ترغبون به باستخدامه. [4:57] دعوني أقدم لكم [4:59] باختصار آلية عمل هذا [5:00] المنشئ. تأتي بفكرة، [5:02] يقوم التطبيق ببنائها [5:03] ، ثم يمكنك معاينتها، [5:05] وإعادة هيكلتها، [5:06] وعذراً، ربما تحسينها [5:07] قليلاً. وفي النهاية، [5:09] المشروع ملكك، أليس [5:10] كذلك؟ لذا تقوم [5:12] بتصديره إلى حسابك على [5:14] GitHub. وكما يعدنا "ريدز" [5:15] ، يمكنك الانطلاق نحو [5:17] الاكتتاب العام. بكل [5:19] بساطة. لنبدأ بالفكرة. [5:22] تذهب إلى "هي-فو-مي" [5:24] وتحدد متطلباتك [5:25] الوظيفية واحتياجات [5:27] العمل. وتعمل مع فريق [5:29] العمل. عندما يأتون [5:30] إليك بفكرتهم، تطرح [5:32] عليهم أسئلة متابعة [5:33] لأن الفكرة لا تكون [5:34] واضحة أبداً. يقوم "هي- [5:36] فو-مي" بهذا العمل [5:37] نيابة عنك. لذا، عندما [5:39] يأتي شخص بفكرة، يطرح [5:40] البرنامج عدة أسئلة [5:41] للمتابعة، وفي [5:42] النهاية يسأل: "هل نحن [5:44] مستعدون للبناء؟" [5:45] دعونا نرى كيف يبدو [5:46] الأمر. هذه لوحة [5:47] التحكم في "هي-فو-مي"، [5:49] وأنا قمت بتسجيل [5:50] الدخول بالفعل. لنبدأ [5:52] مشروعاً جديداً. [5:53] المركز الرئيسي عبارة [5:55] عن صندوق إدخال كبير. [5:57] يمكنك فتح قائمة نماذج [5:58] الذكاء الاصطناعي، [6:00] لتختار نماذج مختلفة [6:01] للمهام الفرعية ضمن [6:03] سير العمل. على اليمين [6:04] ، لديك بعض الأفكار [6:06] المقترحة، ولكننا [6:07] اليوم سنبني تطبيقاً [6:08] للياقة البدنية. إذًا، [6:10] قمنا بوضعه كمطالبة [6:12] مبسطة. نبدأ في البناء. [6:14] ها هو ذا. ربما يمكنك [6:16] التعرف على أن هذا هو [6:18] Ruby LLM. نتلقى بعض [6:20] الأسئلة المتابعة، [6:21] لذا نجيب بنعم أو لا، [6:23] أو أي شيء، افعل ما [6:24] تريد اعتمادًا على [6:25] العمق الذي تريد [6:27] الوصول إليه. هناك [6:28] أيضًا سؤال عما إذا [6:29] كنت تريد تضمين بعض [6:31] البيانات التجريبية [6:32] في تطبيقك، لأنه بدون [6:34] ذلك سيبدو سيئًا [6:35] للغاية. وعندما تكون [6:37] هناك بعض البيانات [6:38] التجريبية، فإنه [6:40] يتألق حقًا. لذا أقوم [6:42] بإرسال الإجابات. الآن [6:44] السؤال هو: "حسنًا، هذا [6:45] ما أفهمه عن تطبيقك. هل [6:47] تريد البدء في البناء؟ [6:50] " نعم، من فضلك. ونحصل [6:55] بسرعة على إجابة من [6:56] المساعد. حسنًا، لقد [6:58] بدأ البناء. هذا [7:00] مجددًا ما أفهمه عن [7:01] التطبيق. يمكنني [7:03] الانتقال إلى [7:04] المعاينة ويمكنني [7:05] رؤية أن هناك خطة سيتم [7:07] تنفيذها للوصول إلى [7:09] هذا التطبيق. إذًا، [7:12] الآن الخطة. كل تغيير [7:16] يحتاج إلى خطة تنفيذ. [7:19] بالطبع، يمكننا فقط [7:20] تشغيل مطالبة [7:21] المستخدم مباشرة كما [7:23] في slash golden clothes على [7:24] سبيل المثال، ويمكننا [7:26] البناء باستخدام وكيل [7:28] لكل ما يطلبه المستخدم [7:29] . لكن للوصول إلى تطبيق [7:31] رائع، نحتاج حقًا إلى [7:33] سد الفجوات التي لم [7:35] يعرف المستخدم أن [7:36] يطلبها، لأنه كما تعلم [7:38] على الأرجح في البرمجة [7:40] الوكيلية، أي شيء لا [7:42] تقوله سيُستخدم ضدك [7:44] بطريقة أو بأخرى. لذا، [7:46] لنتمكن من بناء هذا [7:48] التطبيق، نريد البدء [7:49] أولاً بوضع خطة تنفيذ [7:51] مقسمة إلى مراحل. إذًا [7:55] ، دعونا نعود إلى [7:56] الحلم الأصلي لـ Ruby on [7:58] Rails. لقد وضعت هذه [7:59] المطالبة: "أود الحصول [8:01] على مدونة جميلة بها [8:03] منشورات وتعليقات" في [8:04] He for Me. أجاب بـ خطة من [8:06] خمس خطوات. تبدأ [8:08] بإضافة نموذج [8:09] المنشورات والتعليقات [8:10] ، ثم التخطيط، ثم بعض [8:12] البيانات الأولية [8:13] لقاعدة البيانات، [8:14] وأخيرًا اختبار [8:16] التكامل الشامل. تبدو [8:17] جيدة جدًا. لكن، الخطة [8:19] ليست مجرد مجموعة من [8:21] تلك الملخصات، وتلك [8:22] الجمل السريعة. كل [8:24] خطوة هي مطالبة مفصلة [8:26] لأداة وكيلية لتنفيذ [8:27] هذه الخطوة المحددة [8:29] للغاية. هذا مجرد [8:31] مقتطف، إنه يستمر [8:32] ويستمر، إنه يشبه صفحة [8:34] من النص لكل خطوة من [8:35] الخطوات. وعندما يتم [8:37] تنفيذ كل شيء، تؤدي [8:39] هذه المطالبة وهذه [8:40] الخطة إلى هذا. كان [8:44] بإمكاننا طلب نوع معين [8:45] من التخطيط، نوع معين [8:47] من الترتيب. لم نفعل [8:49] ذلك، لذا قرر He for Me [8:51] المضي قدمًا في هذا. [8:53] لكن، أحلام ديفيد لا [8:55] تستقر على هدف واحد، [8:57] أليس كذلك؟ لقد سمعتم [8:59] اليوم. سمعت أن هناك [9:01] حلماً جديداً، جزء من [9:02] الذكاء الاصطناعي، [9:04] يتعلق بجعل كل شيء [9:05] يدور حول أمارشي. لذا، [9:07] أدخلت هذا الأمر: "حوّل [9:09] المدونة حول أمارشي [9:11] إلى مشروع محادثة He for [9:12] Me". ومرة أخرى، حصلت [9:14] على خطة. إعادة علامة [9:16] تجارية، إعادة تصميم، [9:18] إعادة تنسيق، وهكذا. [9:19] كل خطوة، مرة أخرى، هي [9:22] أمر كامل للتنفيذ [9:23] الوكالي. وعندما انتهى [9:26] كل شيء، تحولت مدونتنا [9:28] إلى هذا. تصميم جديد، [9:30] خطوط جديدة، ومحتوى [9:32] جديد. بشكل أساسي، [9:34] قمنا بإنشاء تطبيق [9:35] بسرعة وقمنا بتعديله [9:37] ليلبي احتياجاتنا [9:38] الجديدة. لذا، باختصار [9:41] ، مع تطبيق Hif for Me، [9:43] كلما بدأت التطبيق، [9:45] فإنه يبني أولاً خطة [9:47] تنفيذ. تستند الخطة [9:48] إلى حقيقة أن Hifumi يبدأ [9:50] دائماً بهيكل تطبيق [9:52] Rails جديد. لذا، فهو لا [9:54] ينشئه من الصفر أبداً. [9:56] يبدأ بنسخ بعض الملفات [9:58] . ثم، قبل أن يبدأ Hifumi [10:00] في التنفيذ، يفكر [10:01] أيضاً في قالب الواجهة [10:03] الأمامية الذي يجب [10:04] استخدامه، ونوع [10:05] الألوان، ونوع الخطوط [10:07] ، فقط لاستبعاد ذلك من [10:09] التنفيذ اللاحق. لذا، [10:11] مع إنشاء هذه الخطة، [10:12] أفضل تلميح يمكنني [10:14] تقديمه لكم يا رفاق، [10:15] كلما قمتم ببناء مولد، [10:17] فإن النقطة الأخيرة هي [10:18] الأكثر أهمية. ضع [10:20] الميزة الرئيسية في [10:21] مسار الجذر، لأنه [10:22] بخلاف ذلك، قد ينشئ [10:24] Hifumi أفضل تطبيق في [10:25] العالم، وتفتحه، ولا [10:27] تجد شيئاً. لذا، هذا [10:29] أمر ضروري للغاية. ومع [10:31] ذلك، عندما نريد تعديل [10:33] الخطة، يكون للخطة شكل [10:34] مختلف قليلاً. علينا [10:36] التأكد من أن الوكيل [10:38] الذي سيقوم في النهاية [10:40] ببناء التطبيق أو [10:41] التعديل، يفهم أن [10:42] التطبيق موجود بالفعل [10:44] ، وأنه يجب عليه [10:45] تعديله، وليس مجرد [10:47] إعادة إنشاء كل شيء من [10:49] الصفر. حسناً. إذاً، [10:51] لدينا خطة. الخطة [10:52] جاهزة، ومقسمة إلى [10:54] مراحل. الآن، نريد [10:55] بناء تطبيق Rails الجديد. [10:59] لقد رأيتم هذا بالفعل. [11:01] هذه هي الخطة في Hifumi، [11:03] حيث يتم تمييز كل [11:05] مرحلة بأنها مكتملة، [11:06] أو قيد الإنشاء، أو [11:08] معلقة. سأقوم بالتشغيل [11:10] قليلاً. لذا، يمكنك [11:12] رؤية أن جزء الإنشاء [11:15] قد اكتمل، والآن يتم [11:16] تنفيذ المرحلة [11:18] التالية. لدينا [11:19] تغييرات حية، بفضل [11:21] Hotwire وإشعارات دعم [11:23] النشاط. الآن، قليلاً [11:29] عن لغة النطاق الخاصة [11:31] بـ Hifumi. لقد قلت أن [11:32] لدينا خطة مقسمة إلى [11:34] مراحل. المصطلح الخاص [11:36] في Hifumi لمرحلة واحدة [11:38] من الخطة هو "مراجعة"( [11:40] revision). لذا يتم تقسيم [11:42] الخطة إلى مراجعات [11:44] تشكل معاً الخطة [11:45] الكاملة. كل مراجعة، [11:48] كما رأيتم، لها هدف، [11:50] وملخص بجملة واحدة، [11:52] ونطاق عمل. الآن كل [11:57] مراجعة، أي كل عنصر في [12:00] الخطة وكل مرحلة من [12:02] الخطة، يتم تنفيذها [12:04] ضمن سير العمل. سير [12:06] العمل هو مجموعة من [12:07] الخطوات. بعض هذه [12:08] الخطوات حتمي وبعضها [12:10] يعتمد على النماذج [12:11] اللغوية الكبيرة (LLM). [12:13] عندما تنتهي المراجعة [12:15] وتصبح جاهزة، نحصل على [12:17] التزامين (commits) في [12:19] مستودع Git. أحدهما [12:21] يتضمن الكود المعدل [12:22] والآخر يتضمن التوثيق. [12:29] يتم تنفيذ سير العمل [12:31] باستخدام Roast. Roast هي [12:34] لغة برمجة مفتوحة [12:35] المصدر من Shopify تعتمد [12:37] على Ruby لسير العمل، [12:39] خاصة تلك التي تمزج [12:40] بين تغييرات الكود [12:42] الحتمية وتلك القائمة [12:43] على النماذج اللغوية. [12:47] كان بإمكاني هنا [12:48] استخدام Ruby LLM لجزء سير [12:50] العمل أيضاً. لكنني [12:53] أردت فصلاً واضحاً بين [12:55] Ruby LLM، أي التحدث مع [12:57] النموذج اللغوي، وبين [13:00] جزء سير العمل. أردت أن [13:03] أسأل كم منكم استخدم [13:06] Ruby LLM، لكنني لا أستطيع [13:08] رؤيتكم. لذا لن أفعل، [13:10] لكن آمل أنكم جميعاً [13:12] قمتم بالتحديث إلى Ruby [13:14] LLM 2.0 الذي تم إصداره [13:16] مؤخراً. وأشكر كارمين [13:18] حقاً على إنشاء Ruby LLM [13:20] الذي تمكنت من [13:21] استخدامه هنا، فلولاه [13:23] لما وُجد هذا المشروع. [13:26] لقد ذكرت أنني أستخدم [13:28] Ruby LLM وأستخدم Roast لفصل [13:30] هذين الجزأين تماماً. [13:33] لذا، باختصار، هاتان [13:35] أداتان رائعتان لأجل [13:37] Hifumi. دعونا نعود إلى [13:39] سير عمل Roast. هذه [13:42] مجموعة من الخطوات [13:44] التي يتم تشغيلها لكل [13:46] مراجعة. أي لكل مرحلة [13:48] من المراحل في الخطة. [13:50] نبدأ ببناء الأوامر ( [13:52] prompt). يبدأ الأمر أولاً [13:55] بمهام المراجعة [13:57] المطلوبة ونطاق العمل. [14:00] ثم يحتوي هذا الأمر [14:01] على التوثيق الذي تم [14:03] إنشاؤه للمشروع حتى [14:05] الآن. كما يحتوي على [14:06] لقطة لما تبدو عليه [14:08] مساحة العمل الحالية. [14:09] ويتضمن أيضاً بعض [14:11] القواعد، على سبيل [14:12] المثال، "افعل ذلك [14:14] بطريقة Rails". أو "املأها [14:16] بالاختبارات". بمجرد [14:18] أن يصبح الأمر جاهزاً، [14:20] نرسله ببساطة إلى Cloud. [14:22] نعم، Hifumi مرتبط تماماً [14:24] بـ Cloud، لأنه أداتي [14:26] المفضلة. بالطبع، يمكن [14:28] إعادة تنفيذه [14:29] باستخدام Codex. لكن هذا [14:31] هو بالضبط سبب احتياجي [14:32] لمفتاح OpenRouter API الخاص [14:34] بك، أو بشكل عام أي API [14:36] متوافق مع Cloud. ويعمل [14:38] بأفضل خيار على [14:39] الإطلاق، وهو "تجاوز [14:41] الأذونات بشكل خطير"، [14:43] لأننا لا نريد سؤال [14:44] مستخدم Hifumi عن أي شيء. [14:47] إذن، هذا الجزء ينفذ [14:49] تغيير المراجعات. بعد [14:52] ذلك، بالطبع، علينا [14:54] التحقق. لكن قبل ذلك، [14:56] ملاحظة واحدة، [14:57] استخدام هذا بهذه [14:59] الطريقة له ميزة كبيرة [15:02] . إنه مجاني على الجهاز [15:03] المحلي (localhost) بشرط أن [15:05] يكون لديك اشتراك في [15:06] Cloud. يمكنك تجربة " [15:08] هيفومي" قدر ما تشاء [15:09] دون دفع قرش واحد [15:11] لتوليد الأكواد أو [15:12] التوثيق. إن المحادثة [15:15] مع النموذج اللغوي عبر [15:17] Ruby LLM لا تزال تعمل على [15:19] OpenRouter، لكنها لا تكلف [15:21] سوى قروش بسيطة. صحيح. [15:24] بمجرد تنفيذ الكود، [15:26] نود التحقق مع كل [15:28] مراجعة: هل لا يزال [15:30] يعمل بشكل سليم؟ هل [15:32] يعمل "باندل"؟ هل يمر [15:34] فحص "سايد كيك"؟ أتحقق [15:36] أيضاً من جميع صفحات " [15:38] جيت" لمعرفة ما إذا [15:39] كانت تظهر أخطاء أم لا. [15:41] وبالطبع، أقوم بتشغيل [15:43] "هيفالامب" الذي ينفذ [15:44] مجموعة الاختبارات [15:46] الكاملة للتطبيق. [15:47] وعندما تجتاز [15:48] الاختبارات، ننتقل [15:49] للمرحلة التالية. لكن [15:50] عند وجود أي أخطاء، [15:52] نحاول إصلاحها أولاً [15:54] بطريقة حتمية. لنفترض [15:56] أن الوكيل نسي تشغيل " [15:57] باندل إنستول". إذن، [15:59] يمكننا القيام بذلك [16:01] هنا. أما إذا لم تكن [16:02] هناك أخطاء حتمية يمكن [16:04] إصلاحها، فإننا نرسل [16:05] مطالبة إصلاح أخرى [16:07] للوكيل مرة أو مرتين [16:08] لمحاولة معالجة الخطأ [16:10] بهذه الطريقة. بمجرد [16:12] الانتهاء من كل ذلك، [16:14] نتحقق مما إذا كان [16:15] الفشل لا يزال قائماً. [16:17] إذا فشل، نقول: "حسناً، [16:19] بناء هذه المراجعة فشل [16:22] "، ونقوم بإعادة [16:23] مستودع "جيت" الخاص بنا [16:26] إلى حالته قبل [16:27] المراجعة، لكنني لم [16:29] أرَ حدوث ذلك منذ 3 [16:31] أشهر في "هيفالامب". [16:36] أما إذا نجح كل شيء، [16:38] نقوم بحفظ الكود، [16:39] وتوليد التوثيق [16:41] الجديد، ثم حفظه أيضاً [16:43] . بعد اكتمال كافة [16:47] المراحل، نرى أن كل [16:49] شيء قد أنجز. وهكذا تم [16:51] تنفيذ خطتنا. ربما أهم [16:54] شيء بخصوص عملية [16:56] البناء هو أين تحدث. [16:58] لأننا لا نستطيع حقاً [17:00] تشغيل كل ذلك الكود [17:02] بصلاحيات خطرة مباشرة [17:04] على الخادم. لذا، كل [17:05] مراجعة تنشئ حاوية " [17:08] دوكر" جديدة. إنها [17:09] حاوية مؤقتة. يمكنك [17:11] رؤية خيار "minus minus rm". [17:14] لذا ستختفي بعد اكتمال [17:15] هذه المراجعة. وبالطبع [17:18] هذا ليس عزلاً كاملاً، [17:20] إنه مجرد "دوكر"، لكنه [17:23] يوفر نوعاً من العزل. [17:25] لذا، كل مراجعة وكل [17:26] عملية "ريلز" تعمل في [17:28] حاوية "دوكر" منفصلة. [17:30] أما الجزء الأكثر متعة [17:32] بالنسبة لي في التنفيذ [17:34] فكان المعاينة. لأنه [17:35] كيف يمكنك معاينة [17:37] تطبيق "ريلز" تم بناؤه [17:39] بواسطة تطبيق "ريلز" [17:41] آخر؟ أولاً، لنلقِ [17:44] نظرة. هذا تطبيق تم [17:46] بناؤه بمطالبة [17:47] مُحسّنة بالكامل. [17:49] يمكنك رؤية طولها. لا [17:51] يوجد شيء تقني فيها. لا [17:53] يوجد أي ذكر لـ "ريلز". [17:56] إنها مجرد احتياجات [17:58] عمل أساسية تماماً. [18:04] لقد بدأ البناء واكتمل [18:06] ، لذا اختفت الخطة. [18:08] أبدأ بالنقر على عرض [18:10] المعاينة. وأحصل على [18:14] الصفحة داخل إطار iframe. [18:17] دعونا نستمتع بالصفحة [18:19] قليلاً. يمكنك التصفح [18:22] من خلالها، كما يمكنك [18:24] فتحها في علامة تبويب [18:26] منفصلة. وفي الدقيقة [18:29] التالية، يرجى [18:30] الاستمتاع. إنه تطبيق [18:32] يعمل لمرة واحدة في [18:33] هيفومي. أردت فقط أن [18:35] أوضح لكم تطبيق Ruby on [18:37] Rails يعمل بالكامل حيث [18:39] يمكنك التسجيل. يمكنك [18:59] العثور على، لا أتذكر [19:01] ما إذا كنت قد ذكرت ذلك [19:03] . هذه صفحة حيث يمكنك [19:04] تنظيم رحلة تنزه، [19:06] ويمكنك العثور على [19:07] رحلة لنفسك. إذن، أردت [19:09] الانضمام إلى هذا، [19:10] لكنه ممتلئ بالفعل. [19:12] لذا، أنا الآن أبحث عن [19:14] رحلة أخرى للانضمام [19:15] إليها. دعونا نذهب إلى [19:17] إنجلترا. شخصان فقط [19:18] قادمان، لذا دعونا [19:20] نطلب منهما أن يأخذانا [19:22] معهما. وعندما أذهب [19:28] إلى حسابي، يمكنني [19:29] رؤية طلب معلق. آه. إذن [19:33] ، لنقل إن الأمر ليس [19:35] معقداً، لكنه صفحة Ruby [19:37] on Rails تعمل بكامل [19:38] طاقتها وتبدو جميلة [19:40] جداً. لذا، دعونا نرى [19:43] كيف تم إنشاء تلك [19:45] المعاينة، وكيف يمكنك [19:47] إطلاق معاينة كهذه [19:49] داخل تطبيق Rails. نبدأ [19:51] باستخدام الكثير من [19:53] Docker. لذا، المصطلحات [19:55] الوحيدة التي [19:56] سأستخدمها هي Docker و Kamal [19:58] proxy. لذا، نبدأ ببناء [20:02] صورة Docker. ثم نقوم [20:05] بتشغيل الحاوية. بكل [20:08] بساطة وسهولة. تشغيل [20:12] Docker مع الكثير من [20:13] السمات. عندما نبدأ [20:15] تشغيل هذه الحاوية في [20:17] بيئة الإنتاج، لا تكون [20:19] مرئية بعد للإنترنت [20:21] العام، لكننا نخبرها [20:23] مسبقاً من خلال وسيط [20:25] مضيف المعاينة عن [20:26] عنوان URL الذي ستظهر [20:28] فيه. لذا، ستكون مرئية [20:31] على project id.preview.hifumi.dev. [20:33] لا ينبغي لي استخدام [20:35] hifumi.dev للمعاينة، لكن [20:36] هذه قصة طويلة. ومع ذلك [20:38] ، في localhost، يكون الأمر [20:40] أسهل بكثير. يمكنني [20:41] ببساطة ربط localhost بأي [20:43] منفذ، أليس كذلك؟ وهذا [20:45] ما نفعله كل يوم. لذا، [20:47] في التطوير، أقوم [20:48] ببساطة بربطه بـ localhost [20:50] والمنفذ 3000 زائد معرف [20:52] المشروع. لذا، سيظهر [20:54] أي مشروع تحت، على [20:56] سبيل المثال، localhost 3010. [20:58] أقوم بتشغيل الحاوية [21:00] الخاصة بي. الصفحة [21:01] تعمل بالفعل. الآن، ما [21:03] أفعله بعد ذلك هو فحص [21:05] الحالة. لذا، أقوم فقط [21:07] باستخدام curl على نقطة [21:08] النهاية/up الخاصة بـ [21:10] Ruby on Rails. وعندما ينتهي [21:11] كل شيء من فحص الحالة [21:13] في بيئة الإنتاج، [21:14] يتعين علي توجيه هذه [21:16] الحاوية إلى العالم [21:17] الخارجي. لذا، أقوم [21:19] بتشغيل Docker exec camel proxy [21:20] مرة أخرى مع مجموعة من [21:22] السمات الأخرى. بعد [21:23] هذه الخطوة، يمكن لأي [21:25] شخص الوصول إلى هذا [21:26] الموقع. وبما أن [21:29] العملية برمتها تتم من [21:31] خلال مهمة Solid Queue، [21:33] فأنا لا أزال أحافظ [21:35] على سياق تطبيق Hifumi Rails [21:37] . ويمكنني ببساطة بث [21:40] التغيير إلى المستخدم [21:41] الذي طلب المعاينة. [21:44] لذا، كل ما أفعله هو [21:46] البث، ويقوم Hifumi بعرض [21:48] إطار iframe يشير إلى [21:50] صفحتنا الجديدة. لم [21:53] يكن أي من هذا لينجح لو [21:55] لم تكن لدينا قدرات [21:57] المعالجة غير [21:58] المتزامنة في Rails. لذا، [22:00] يتم تأجيل جميع [22:01] العمليات التي تستهلك [22:03] موارد كثيرة إلى [22:04] المعالجة في الخلفية، [22:05] بالطبع. لكن، مع كل هذا [22:07] التعقيد في Hifumi، فإنه [22:09] يستخدم خمس مهام فقط. [22:13] حتى الرسالة الواردة [22:15] لدردشة LLM هذه يتم [22:17] تأجيلها إلى مهمة Solid [22:19] Queue. وما تراه، الرد من [22:22] الوكيل، وجميع [22:24] الإجراءات يتم [22:25] تسليمها عبر Hotwire. الآن [22:29] ، قبل أن أبني Hifumi، [22:31] خططت لتقديم عرض آخر [22:33] في Rails World. وكان من [22:35] المفترض أن يكون حول [22:36] نمط الناشر والمشترك ( [22:38] Pub-Sub)، وهو موضوع أحبه [22:40] حقاً وربما أتحدث عنه [22:41] العام المقبل. في Rails، [22:44] لديك آلية قوية جداً [22:46] تسمى Active Support Notifications، [22:49] حيث يمكنك نشر حدث [22:50] والاشتراك فيه [22:52] لاستهلاكه والاستجابة [22:54] له. لذا، في اللحظات [22:58] المهمة في Hifumi، أقوم [23:00] بنشر أحداث، مجدداً [23:02] خمسة منها فقط، [23:03] ويمكنني الاشتراك [23:05] فيها. على سبيل المثال [23:07] ، عندما يتم طلب خطة [23:09] جديدة، أي أننا على [23:11] وشك بناء شيء ما، يسمى [23:13] الحدث "instruction requested"، [23:15] مما يعني أننا بصدد [23:17] بناء خطة جديدة. لذا، [23:19] إذا كنت تبني شيئاً ما [23:20] ، فمن المحتمل أننا [23:22] يجب أن نغلق المعاينة [23:23] إذا كان هناك أي منها [23:25] يعمل لهذا المشروع. [23:26] لذا، كلما تم طلب خطة [23:28] جديدة، أضع مهمة إيقاف [23:30] المعاينة، وأقوم [23:31] بإدراجها في قائمة [23:33] الانتظار لإيقاف [23:34] المعاينات التي تعمل. [23:37] بهذه الطريقة، يمكنني [23:39] فصل جانبي التطبيق [23:41] بشكل كامل، جانب [23:42] البناء وجانب [23:44] المعاينة، دون أي [23:45] اتصال مباشر بينهما. [23:50] ربما الجزء الأكثر [23:52] أهمية هو أن المشروع [23:54] ملك لك، وليس لـ Hifumi، [23:56] وليس لي. لذا، عندما [23:59] تنتهي من البناء أو في [24:01] أي مرحلة من عملك، [24:02] يمكنك تصديره بسهولة [24:04] إلى مستودع GitHub خاص بك. [24:07] يمكنك مراجعة ذلك [24:08] لاحقاً لأن كل مراجعة [24:10] تم حفظها في نسختين [24:12] منفصلتين (commits). وحتى [24:15] بعد التصدير، يمكنك [24:16] الاستمرار في البناء [24:18] باستخدام Hifumi ودفع [24:20] الالتزامات (commits) [24:21] التالية التي تضيفها [24:23] لاحقاً. دعونا نرى كيف [24:25] يعمل ذلك. لنعد إلى [24:27] تطبيق اللياقة [24:28] البدنية الذي بدأت في [24:29] بنائه في البداية. لقد [24:31] قمت بالفعل بالتفويض [24:32] عبر GitHub لأنه لا يوجد [24:34] شيء مثير للاهتمام [24:35] هناك. ولكن إذا انتقلت [24:37] إلى التصدير، يمكنني [24:38] ببساطة النقر على [24:39] تصدير إلى GitHub، وهذا [24:40] متاح مدى الحياة في [24:42] الواقع. يمكنني الآن [24:45] الانتقال إلى GitHub [24:46] وإلقاء نظرة على الكود [24:48] . تم إرسال جميع [24:49] التغييرات بواسطة [24:51] hifumi.dev. لننتقل إلى [24:52] وحدات التحكم (Controllers). [24:55] تبدو وحدة تحكم [24:57] التدريبات وكأنها [24:58] وحدة تحكم Rails تم [25:00] إنشاؤها للتو، بسيطة [25:02] للغاية. دعونا نلقي [25:05] نظرة على وحدة تحكم [25:06] التقويمات الأخرى، [25:08] فهي تحتوي على المزيد [25:10] من منطق النطاق. لذا، [25:14] قد تتساءل عما يمكنك [25:16] بناؤه فعلياً [25:17] باستخدام Hevo me؟ هل [25:19] سيكون مفيداً لجميع [25:21] أمثلة غير التقنيين [25:22] وكل أفكارهم؟ لنلقِ [25:25] نظرة. لنبدأ بالنظر [25:28] إلى الصفحة المقصودة [25:29] لصالة ألعاب رياضية ( [25:31] جيم). مرة أخرى. أليس [25:39] كذلك؟ مجرد صفحة [25:40] مقصودة، لا يوجد منطق [25:42] بداخلها، تبدو جيدة [25:44] فقط. هذه بوابة [25:45] للتصميم الداخلي مع [25:47] مساعد تصميم. يمكنك [25:50] تحديد غرفك، أثاثك، [25:52] ميزانيتك، وتنظيم شقة [25:55] ذات مظهر جميل لنفسك. [25:58] منصة تواصل اجتماعي [25:59] للمشي لمسافات طويلة، [26:01] لقد نظرنا إليها [26:02] بالفعل. أوه، هذه صفحة [26:10] اجتماعية أخرى [26:12] لمشاركة أغلى لحظاتك [26:14] مع عائلتك. تطبيق [26:22] موارد بشرية للشركة [26:24] لإدارة الوقت وأيام [26:25] الإجازة والجداول [26:27] الزمنية داخل الوكالة. [26:34] هذا مخطط لمسار [26:36] المؤتمر. لذا، يمكنك [26:39] إضافة مؤتمر، وإضافة [26:41] متحدثين، وإضافة جدول [26:43] أعمال، ويمكنك نشره [26:44] تحت رابط عام حتى [26:46] تتمكن من مشاركته مع... [26:51] مع الحضور. وأخيراً، [26:53] مدير أسطول الشركة، [26:55] حيث يمكنك إضافة [26:57] المركبات، وتتبع [26:59] استهلاك الوقود، [27:00] والحصول على تقارير، [27:02] وسائقين، وما إلى ذلك. [27:05] لذا، هو أكثر تعقيداً [27:07] قليلاً وأكثر توجهاً [27:09] نحو تطبيقات B2B. لذا، [27:11] أود أن أقول إنه مزيج [27:13] من الجمال والوظائف. [27:15] وكل هذه تم بناؤها [27:16] باستخدام Ruby on Rails [27:18] وبواسطة Ruby on Rails. [27:21] وبشكل أساسي، تم تنفيذ [27:23] كل هذه إما بضربة [27:25] واحدة أو مع بعض [27:26] التعديلات الطفيفة [27:28] لاحقاً. هذه هي قوة Rails [27:34] التي يمكننا [27:35] استخدامها مع كل [27:37] المزايا التي [27:38] اكتسبناها على مدى [27:39] العشرين عاماً [27:40] الماضية تقريباً. كل [27:45] الاتفاقيات، وكل [27:46] عقلية الاختبار أولاً [27:48] ، وكل الأشياء التي [27:50] نمتلكها جاهزة [27:51] للاستخدام داخل Rails. مع [27:53] كل الاتفاقيات التي [27:55] تفهمها النماذج [27:56] اللغوية الكبيرة (LLMs) [27:57] بشكل أفضل وأفضل. لذا، [27:59] مع خطة جيدة وتخطيط [28:01] جيد لتلك الخطط، [28:02] وأجزاء جيدة، [28:03] ومراجعات جيدة، يمكنك [28:05] استخدام هذه التقنية [28:07] مع Hifumi أو بدونها في [28:09] عملك اليومي. ولكن، [28:12] أدعوكم بشدة لزيارة [28:14] hifumi.dev، وتجربته، [28:16] والأهم من ذلك، نسخه [28:18] وتشغيله والاستمتاع [28:20] والبناء باستخدام Ruby on [28:23] Rails. لأنني أعتقد حقاً [28:26] أن "روبي أون ريلز" [28:27] مهيأة تماماً لعصر [28:29] الوكلاء الذكيين. [28:31] شكراً جزيلاً لكم.