كتاب تمهيدي من تأليف مستخدمى الإنترنت koalant (يرجى تسجيل الدخول للتنزيل) يقدم لغة روبي وتثبيت ريلز ومثال بسيط. مفيدة جدا للمبتدئين. موصى به للغاية!
إذا كنت منخرطًا في تطوير j2ee كمبرمج Java، فستستخدم بالتأكيد العديد من أطر التطبيقات. لا توجد لغة نشطة مثل مجتمع لغة Java، وأي مفهوم برمجة جديد سيكون له قريبًا تطبيقات مفتوحة المصدر مقابلة على الإنترنت. وفقًا لنموذج تطوير مواقع الويب الأكثر استخدامًا MVC، ستحتوي كل طبقة على العديد من الأطر الدعامات والنسيج التي تنتمي إلى طبقة التحكم (C)، وينتمي إطار السرعة إلى طبقة العرض (V). يكون Hibernate أو iBatis أو OJB أو أي من تطبيقات JDO العديدة مفتوحة المصدر، مثل JPOX. ولكن وجود عدد كبير للغاية من الخيارات ليس بالضرورة أمرا جيدا، ولا يستطيع الجميع أن يتبنى الإطار الصحيح للقيام بالشيء الصحيح. إذا كان نظام التطوير الخاص بك هو .net، فيمكنك تجنب هذا الموقف عادةً ما تحتاج فقط إلى تثبيت Visual Studio .net كأداة تطوير، ثم تثبيت MSDN للعثور على المعلومات. بالنسبة لمطوري البرامج، هذا وضع صعب للغاية. أنا شخصيًا أحب Java كثيرًا، سواء أكان ذلك للتعلم أو الممارسة، فهي توفر لنا الكثير. ولكن لماذا أعتقد أن الحلول "الشاملة" مثل .net صحيحة عدة مرات؟
باعتباري مبرمج Java، أعتقد أن بعض المشكلات الأكثر وضوحًا في Java هي أولاً وقبل كل شيء، Java معقدة للغاية، وثانيًا، Java موجهة جدًا للمبرمجين وليست موجهة للمستخدم. مقارنة بـ C++، تعد Java بسيطة جدًا بالفعل. توضح حقيقة وجود الكثير من مبرمجي Java الآن هذه النقطة. ولكن كما قال أحدهم ذات مرة، "في Linux، يمكنك بسهولة معرفة من هو السيد"، لكن الأمر ليس بهذه السهولة في مجال Java. غالبًا ما أجد أن زملائي من حولي ما زالوا يرتكبون أخطاء مفاهيمية منخفضة المستوى للغاية، ولا يزال بإمكانهم الانخراط في تطوير j2ee لسنوات عديدة حتى لو لم يتمكنوا من التمييز بدقة بين الواجهات والفئات المجردة والسيرفلتس. ولكن لماذا يقال أن Java معقدة لأنها تتطلب الكثير من التقنيات المختلفة لإنجاز شيء واحد؟ لذا، بالنسبة للمبرمجين الذين ليس لديهم مفاهيم واضحة جدًا، كيف يمكنك التأكد من قيامهم بالاختيار الصحيح؟ وكم عدد الأطر العديدة التي توفر خدمات "الشباك الواحد"؟ يوفر إطار عمل Spring الذي ظهر مؤخرًا أكبر عدد من الخدمات بين العديد من أطر العمل، لكن لديه مشكلة جديدة، وهي أنه لا يزال موجهًا جدًا للمبرمجين، وليس للمستخدمين. لماذا تقول ذلك؟ تم تصميم الأطر في الأصل للمبرمجين، أليس هذا صحيحًا؟ على الرغم من أن Spring يوفر العديد من الخيارات (ولكن ليس كافيًا، فهو لا يحتوي على ORM بحد ذاته)، إلا أنه لا يوفر طريقة بسيطة لاستخدامه، لذلك لا يمكننا إلا أن نقول إنه مخصص للمبرمجين. تواجه معظم أطر عمل جافا هذه المشكلة، أي أن منحنى التعلم مرتفع نسبيًا. أعتقد أن مستوى منحنى التعلم هو المفتاح للتمييز بين ما إذا كان إطار العمل مخصصًا للمبرمجين أو للمستخدمين، وأعتقد أن هذا ينعكس بشكل أساسي في سهولة استخدام الإطار. في الواقع، المستخدمون النهائيون لإطار العمل هم المبرمجون. السبب وراء استخدامنا لـ "المستخدمين" و"المبرمجين" للتمييز هو أن بعض أطر العمل "للمبرمجين" يصعب استخدامها، على الرغم من أنها توفر كمية كبيرة من البنية التحتية والأجزاء. ما زالوا بحاجة إلى أن يقوم المبرمجون بتجميعها بأنفسهم. الإطار الموجه نحو "المستخدم" أبسط، ويحتاج المستخدمون فقط إلى اتباع التعليمات لاستخدامه. لماذا ستثير Ruby on Rails ضجة كبيرة في مجتمع Java، أعتقد أن السبب هو أنها توفر إطار عمل "شامل" وموجه نحو المستخدم وبسيط وسهل الاستخدام، وهو ما يفتقر إليه إطار عمل Java. لماذا تستطيع Ruby on Rails القيام بذلك، أليس من الممكن أن Java نفسها لا تستطيع القيام بذلك؟ الحقيقة هي أن العديد من مصممي أطر عمل Java لا يفعلون ذلك. ربما كان تفكيرهم يقتصر على كيفية استخدام الأنماط لتصميم إطار عمل جيد، ولم يفعلوا المزيد بشأن سهولة استخدام الإطار. يعرف أي شخص استخدم Spring أن ملف تكوين xml الخاص به سوف يتوسع تدريجيًا، على الرغم من أنه يمكننا بسهولة تقسيمه إلى ملفات تكوين أصغر لحل هذه المشكلة. ولكن عند استخدام ملفات تكوين xml، فإنه يتبع المفهوم المعتاد لبرمجة Java: "Java هي أفضل لغة برمجة، وXML هي أفضل لغة لوصف البيانات، والجمع بين الاثنين هو الأكثر مثالية. إذا لم يستخدم التطبيق xml لوصفه، فهو ليس تطبيق جافا جيدًا."
ومع ذلك، في هذه النقطة تتميز Ruby on Rails عن العديد من أطر عمل Java وتحقق طفرة في سهولة استخدام إطار العمل. تنطبق هذه الفكرة على تصميم Rails بأكمله: التقليد على التكوين. على سبيل المثال، عندما نكتب تطبيقات ويب Java، فإننا عادةً ما نميز الفئات المقابلة وفقًا لـ MVC. أنا شخصياً أحب وضع فئة وحدة التحكم في دليل الويب، وفئة العرض في دليل العرض، وفئة النموذج في دليل المجال . لكن الأشخاص المختلفين لديهم إعدادات مختلفة وأسماء مختلفة. كيف يمكن السماح لإطار العمل بمعرفة هذه الدلائل المختلفة؟ الحل الوحيد لإطار عمل Java هو السماح له بمعرفة هذه المعلومات من خلال ملف تكوين xml. حل ريلز هو: أقوم بتحديد بنية الدليل، وكل ما عليك فعله هو وضع الأشياء في الدليل الذي حددته. وهذا سبب مهم لوجود عدد قليل جدًا من ملفات التكوين في Rails (ولكن ليس لا شيء). على الرغم من أن الفكرة بسيطة جدًا، إلا أن الفائدة التي تقدمها هي أن كفاءة تطوير Rails تبلغ 10 أضعاف كفاءة تطوير Java (هذا ما يدعيه معجبو Rails، لكنني أؤمن بذلك، وأعتقد أنك ستعرفه أيضًا بعد قراءة هذا المقال) ) . فهل هذا وحده يجعل تطوير القضبان أسرع من استخدام جافا؟ ليس تمامًا، لأن هذا يستفيد أيضًا من فلسفة تصميم أخرى لـ Rails: كود أقل. لا يمكن لأي لغة أن تدعي ذلك. مع Ruby، يمكنك بالفعل كتابة الكثير من الوظائف بكمية صغيرة من اللغة وهو أمر غير ممكن مع اللغات الأخرى. لإتقان ريلز، عليك أن تفهم روبي. قال أحدهم ذات مرة: Zope (إطار عمل ويب python الشهير) هو تطبيق قاتل للبايثون، والبايثون هو سلاح zope السري. أعتقد أن هذه الجملة هي الأنسب لوصف العلاقة بين ريلز وروبي.
