عرض مصدر Rails/initialization

<noinclude>{{DISPLAYTITLE:عملية تهيئة ريلز}}</noinclude>
[[تصنيف:Rails]]
يشرح هذا الدليل العمل الداخلي لعملية التهيئة في ريلز. وهو دليل متعمق للغاية وموصى به لمطوري ريلز المتقدمّين.

ستتعلم بعد قراءة هذا الدليل:
* كيفيّة استخدام خادم ريلز (rails server).
* التسلسل الزمني لتهيئة ريلز.
* أين تُطلَب الملفّات المختلفة أثناء تسلسل التمهيد.
* كيفيّة تعريف واجهة <code>Rails::Server</code> واستخدامها.
يتضمّن هذا الدليل كل استدعاء لتابع مطلوب لتشغيل مكّدس Ruby on Rails (أي stack) لتطبيق ريلز افتراضي، مع شرح كل جزء بالتفصيل. بالنسبة لهذا الدليل، سنركّز على ما يحدث عند تنفيذ rails server لبدء إقلاع (boot) تطبيقك.

المسارات في هذا الدليل نسبيّة إلى Rails أو تطبيقات Rails ما لم يذكر خلاف ذلك.

نوصيك باستخدام المفتاح t المربوط لفتح الباحث عن الملف داخل GitHub والعثور على الملفّات بسرعة إن أردت المتابعة أثناء تصفح [https://github.com/rails/rails شيفرة ريلز المصدرية].

== إطلاق! ==
لنبدأ بالإقلاع وتهيئة التطبيق. يبدأ تطبيق ريلز عادةً بتشغيل <code>rails console rails server</code> أو <code>rails server</code>.

=== الملف railties/exe/rails ===
يحتوي هذا الملف على ملفّ روبي قابل للتنفيذ في مسار تحميلك. ويحتوي على الأسطر التالية:<syntaxhighlight lang="ruby">
version = ">= 0"
load Gem.bin_path('railties', 'rails', version)
</syntaxhighlight>سترى إن جرّبت هذا الأمر في وحدة تحكّم ريلز أنه يحمّل الملف railties/exe/rails. يحتوي جزء من ملف railties/exe/rails.rb على الشفرة التالية:<syntaxhighlight lang="ruby">
require "rails/cli"

</syntaxhighlight>يستدعي الملف railties/lib/rails/cli بدوره <code>Rails::AppLoader.exec_app</code>.

=== الملف railties/lib/rails/app_loader.rb ===
الهدف الأساسي من الدالّة <code>exec_app</code> هو تنفيذ <code>bin/rails</code> لتطبيقك. إن لم يحتوي المجلّد الحالي على <code>bin/rails</code>، فسيتنقل إلى الأعلى حتى يعثر على ملف <code>bin/rails</code> للتنفيذ. وبالتالي يمكن للمرء استدعاء الأمر <code>rails</code> من أي مكان داخل تطبيق ريلز.

بالنسبة للأمر <code>rails server</code>، يُنفّذ الأمر المكافئ للأمر التالي:<syntaxhighlight lang="shell">
$ exec ruby bin/rails server
</syntaxhighlight>

=== <code>bin/rails</code> ===
خذ الملف التالي على سبيل المثال:<syntaxhighlight lang="shell">
#!/usr/bin/env ruby
APP_PATH = File.expand_path('../config/application', __dir__)
require_relative '../config/boot'
require 'rails/commands'
</syntaxhighlight>سيُستخدم الثابت <code>APP_PATH</code> لاحقًا في <code>rails/commands</code>. الملف config/boot المشار إليه هنا هو الملف config/boot.rb في تطبيقنا وهو المسؤول عن تحميل Bundler وإعداده.

=== الملف config/boot.rb ===
يحتوي الملف config/boot.rb على:<syntaxhighlight lang="ruby">
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)
 
require 'bundler/setup' # Set up gems listed in the Gemfile.
</syntaxhighlight>في تطبيق ريلز قياسي، يوجد الملف Gemfile الذي يعلن عن كل اعتماديّات (dependencies) التطبيق. يضبط الملف config/boot.rb المتغيّر <code>ENV['BUNDLE_GEMFILE']‎</code> إلى موقع هذا الملف. إن وُجد Gemfile، يصبح وجود bundler/setup ضروريًّا.

يعتمد أي تطبيق قياسي في ريلز على العديد من الجواهر (gems) تحديدًا:
* actioncable
* actionmailer
* actionpack
* actionview
* activejob
* activemodel
* activerecord
* activestorage
* activesupport
* arel
* builder
* bundler
* erubi
* i18n
* mail
* mime-types
* rack
* rack-test
* rails
* railties
* rake
* sqlite3
* thor
* tzinfo

=== الملف rails/commands.rb ===
بمجرّد الانتهاء من الملف config/boot.rb، الملف المطلوب التالي هو rails/commands الذي يساعد في توسيع الأسماء البديلة. تحتوي المصفوفة <code>[[Ruby/ARGF/argv|ARGV]]</code> في الحالة الحاليّة على الخادم <code>server</code> الذي سيُمرّر:<syntaxhighlight lang="rails">
require_relative "command"
 
aliases = {
  "g"  => "generate",
  "d"  => "destroy",
  "c"  => "console",
  "s"  => "server",
  "db" => "dbconsole",
  "r"  => "runner",
  "t"  => "test"
}
 
command = ARGV.shift
command = aliases[command] || command
 
Rails::Command.invoke command, ARGV
</syntaxhighlight>كانت ريلز لتستخدم الأسماء البديلة <code>aliases</code> لو استخدمنا <code>s</code> بدلاً من <code>server</code> هنا للعثور على الأمر المطابق.

=== الملف rails/command.rb ===
عندما يكتب الشخص أمر ريلز، يحاول <code>invoke</code> البحث عن أمر لمجال الاسم المحدد وتنفيذ الأمر إن عثر عليه.

تسلّم ريلز زمام الأمور إلى Rake إن لم يتعرّف على الأمر لتشغيل مهمة بنفس الاسم.

يعرض <code>Rails::Command</code> كما هو موضّح إخراج (output) المساعدة تلقائيًا إن كانت <code>args</code> فارغة.<syntaxhighlight lang="rails">
module Rails::Command
  class << self
    def invoke(namespace, args = [], **config)
      namespace = namespace.to_s
      namespace = "help" if namespace.blank? || HELP_MAPPINGS.include?(namespace)
      namespace = "version" if %w( -v --version ).include? namespace
 
      if command = find_by_namespace(namespace)
        command.perform(namespace, args, config)
      else
        find_by_namespace("rake").perform(namespace, args, config)
      end
    end
  end
end
</syntaxhighlight>باستخدام الأمر <code>server</code>، ستعمل ريلز أيضًا على تشغيل الشيفرة التالية:<syntaxhighlight lang="rails">
module Rails
  module Command
    class ServerCommand < Base # :nodoc:
      def perform
        set_application_directory!
 
        Rails::Server.new.tap do |server|
          # Require application after server sets environment to propagate
          # the --environment option.
          require APP_PATH
          Dir.chdir(Rails.application.root)
          server.start
        end
      end
    end
  end
end
</syntaxhighlight>سيتغيّر هذا الملف ليصبح المجلّد الجذر لريلز (مسار فوق <code>APP_PATH</code> بمُجلّدين الذي يشير إلى config/application.rb) ولكن فقط إن لم يُعثر على الملف config.ru. يبدأ بعدئذٍ الصنف <code>Rails::Server</code>.

=== الملف actionpack/lib/action_dispatch.rb ===
إرسال الفعل (Action Dispatch) هو مكوّن التوجيه في إطار ريلز. ويضيف وظائف مثل التوجيه (routing)، والجلسات، والبرمجيّات الوسيطة المشتركة.

=== الملف rails/commands/server/server_command.rb ===
يُعرّف الصنف <code>Rails::Server</code> في هذا الملف بالوراثة من <code>Rack::Server</code>. عند استدعاء <code>Rails::Server.new</code>، يُستدعى التابع <code>initialize</code> في rails/commands/server/server_command.rb:<syntaxhighlight lang="rails">
def initialize(*)
  super
  set_environment
end
</syntaxhighlight>أولًا، يُستدعَى <code>super</code> والذي يستدعي بدوره التابع <code>initialize</code> على <code>Rack::Server</code>.

=== الملف Rack: lib/rack/server.rb ===
الصنف <code>Rack::Server</code> هو المسؤول عن عن توفير واجهة خادم مشتركة لكل التطبيقات القائمة على Rack والتي أصبحت ريلز جزءًا منها الآن.

التابع <code>initialize</code> في <code>Rack::Server</code> يُعيّن زوجين من المتغيرات:<syntaxhighlight lang="rails">
def initialize(options = nil)
  @options = options
  @app = options[:app] if options && options[:app]
end
</syntaxhighlight>ستكون <code>options</code> في هذه الحالة هي <code>nil</code>، لذا لا يحدث شيء بهذا التابع.

نقفز بعد الانتهاء من <code>super</code> في <code>Rack::Server</code> إلى rails/commands/server/server_command.rb. في هذه النقطة، تُستدعى <code>set_environment</code> داخل سياق الكائن <code>Rails::Server</code> ولا يبدو أن هذا التابع يعمل بالوهلة الأولى:<syntaxhighlight lang="rails">
def set_environment
  ENV["RAILS_ENV"] ||= options[:environment]
end
</syntaxhighlight>في الواقع يفعل التابع <code>options</code> هنا الكثير. يُعرّف هذا التابع في <code>Rack::Server</code> كما يلي:<syntaxhighlight lang="rails">
def options
  @options ||= parse_options(ARGV)
end
</syntaxhighlight>يُعرّف <code>parse_options</code> كما يلي:<syntaxhighlight lang="rails">
def parse_options(args)
  options = default_options
 
  # Don't evaluate CGI ISINDEX parameters.
  # http://www.meb.uni-bonn.de/docs/cgi/cl.html
  args.clear if ENV.include?("REQUEST_METHOD")
 
  options.merge! opt_parser.parse!(args)
  options[:config] = ::File.expand_path(options[:config])
  ENV["RACK_ENV"] = options[:environment]
  options
end
</syntaxhighlight>مع تعيين هذه القيم في <code>default_options</code>:<syntaxhighlight lang="rails">
def default_options
  super.merge(
    Port:               ENV.fetch("PORT", 3000).to_i,
    Host:               ENV.fetch("HOST", "localhost").dup,
    DoNotReverseLookup: true,
    environment:        (ENV["RAILS_ENV"] || ENV["RACK_ENV"] || "development").dup,
    daemonize:          false,
    caching:            nil,
    pid:                Options::DEFAULT_PID_PATH,
    restart_cmd:        restart_command)
end
</syntaxhighlight>لا يوجد المفتاح <code>REQUEST_METHOD</code> في <code>ENV</code>، لذا نستطيع تخطي ذاك السطر. يدمج السطر التالي الخيارات من <code>opt_parser</code> المُعرّف بوضوح في <code>Rack::Server</code>:<syntaxhighlight lang="rails">
def opt_parser
  Options.new
end
</syntaxhighlight>يُعرّف الصنف في <code>Rack::Server</code> ولكن يُعاد تعريفه في <code>Rails::Server</code> لتتّخذ وسائط مختلفة. تابعها <code>!parse</code> يبدو كالتالي:<syntaxhighlight lang="rails">
def parse!(args)
  args, options = args.dup, {}
 
  option_parser(options).parse! args
 
  options[:log_stdout] = options[:daemonize].blank? && (options[:environment] || Rails.env) == "development"
  options[:server]     = args.shift
  options
end
</syntaxhighlight>سيعيد هذا التابع المفاتيح <code>options</code> التي ستتمكّن ريلز بعدها من استخدامها لتحديد كيفيّة عمل خادمها. نقفز بعد الانتهاء من <code>initialize</code> مرة أخرى إلى أمر الخادم حيث يكون <code>APP_PATH</code> (الذي عُيّن سابقًا) مطلوبًا.

=== config/application ===
عند تنفيذ <code>require APP_PATH</code> يُحمّل الملف config/application.rb (تذكّر أن <code>APP_PATH</code> معرّف في <code>bin/rails</code>). يوجد هذا الملف بتطبيقك ويمكنك تغييره حسب احتياجاتك.

=== <code>Rails::Server#start</code> ===
بعد تحميل config/application، يستدعى <code>server.start</code>. يُعرّف هذا التابع كما يلي:<syntaxhighlight lang="rails">
def start
  print_boot_information
  trap(:INT) { exit }
  create_tmp_directories
  setup_dev_caching
  log_to_stdout if options[:log_stdout]
 
  super
  ...
end
 
private
  def print_boot_information
    ...
    puts "=> Run `rails server -h` for more startup options"
  end
 
  def create_tmp_directories
    %w(cache pids sockets).each do |dir_to_make|
      FileUtils.mkdir_p(File.join(Rails.root, 'tmp', dir_to_make))
    end
  end
 
  def setup_dev_caching
    if options[:environment] == "development"
      Rails::DevCaching.enable_by_argument(options[:caching])
    end
  end
 
  def log_to_stdout
    wrapped_app # touch the app so the logger is set up
 
    console = ActiveSupport::Logger.new(STDOUT)
    console.formatter = Rails.logger.formatter
    console.level = Rails.logger.level
 
    unless ActiveSupport::Logger.logger_outputs_to?(Rails.logger, STDOUT)
      Rails.logger.extend(ActiveSupport::Logger.broadcast(console))
    end
  end
</syntaxhighlight>هذا مكان حدوث أوّل إخراج في تهيئة ريلز. ينشئ هذا التابع فخّا للإشارات <code>INT</code>، لذلك إن ضغطت CTRL-C بالخادم سيخرج من العملية. كما يمكننا أن نرى من الشيفرة هنا أنها ستُنشئ المجلّدات tmp/cache و tmp/pids و tmp/sockets. يُفعّل بعدها التخزين المؤقت في التطوير إن استدعي <code>rails server</code> مع <code>dev-caching--</code>. وأخيرًا، يستدعي <code>wrapped_app</code> المسئول عن إنشاء تطبيق Rack، قبل إنشاء وتعيين نسخة لـ <code>ActiveSupport::Logger</code>.

التابع <code>super</code> سيستدعي <code>Rack::Server.start</code> الذي يبدأ تعريفه هكذا:<syntaxhighlight lang="rails">
def start &blk
  if options[:warn]
    $-w = true
  end
 
  if includes = options[:include]
    $LOAD_PATH.unshift(*includes)
  end
 
  if library = options[:require]
    require library
  end
 
  if options[:debug]
    $DEBUG = true
    require 'pp'
    p options[:server]
    pp wrapped_app
    pp app
  end
 
  check_pid! if options[:pid]
 
  # Touch the wrapped app, so that the config.ru is loaded before
  # daemonization (i.e. before chdir, etc).
  wrapped_app
 
  daemonize_app if options[:daemonize]
 
  write_pid if options[:pid]
 
  trap(:INT) do
    if server.respond_to?(:shutdown)
      server.shutdown
    else
      exit
    end
  end
 
  server.run wrapped_app, options, &blk
end

</syntaxhighlight>الجزء المثير للاهتمام بتطبيق ريلز هو السطر الأخير أي <code>server.run</code>. هنا نواجه التابع <code>wrapped_app</code> مرةً أخرى لكن سنستكشفه هذه المرة أكثر (على الرغم من أنه نُفّذ من قبل، وبالتالي كُتب في الذاكرة الآن).<syntaxhighlight lang="rails">
@wrapped_app ||= build_app app
</syntaxhighlight>يُعرّف التابع <code>app</code> هنا على النحو التالي:<syntaxhighlight lang="rails">
def app
  @app ||= options[:builder] ? build_app_from_string : build_app_and_options_from_config
end
...
private
  def build_app_and_options_from_config
    if !::File.exist? options[:config]
      abort "configuration #{options[:config]} not found"
    end
 
    app, options = Rack::Builder.parse_file(self.options[:config], opt_parser)
    self.options.merge! options
    app
  end
 
  def build_app_from_string
    Rack::Builder.new_from_string(self.options[:builder])
  end
</syntaxhighlight>قيم <code>options[:config]‎</code>الافتراضية هي config.ru والتي تحتوي على:<syntaxhighlight lang="rails">
‎‎# لبدء تشغيل التطبيق Rack هذا الملف يُستخدَم من طرف الخوادم التي تعتمد على
 
require_relative 'config/environment'
run <%= app_const %>
</syntaxhighlight>يأخذ التابع <code>Rack::Builder.parse_file</code> هنا المحتوى من الملف config.ru ويحلله باستخدام هذه الشفرة:<syntaxhighlight lang="rails">
app = new_from_string cfgfile, config
 
...
 
def self.new_from_string(builder_script, file="(rackup)")
  eval "Rack::Builder.new {\n" + builder_script + "\n}.to_app",
    TOPLEVEL_BINDING, file, 0
end
</syntaxhighlight>سيأخذ التابع <code>initialize</code> الذي يخص الصنف <code>Rack::Builder</code> الكتلة (block) هنا وينفّذها داخل نسخة من <code>Rack::Builder</code>. هذا مكان حدوث أغلبيّة عمليّة التهيئة لريلز. وأوّل ما ينفّذ هو السطر <code>require</code> من أجل config/environment.rb في config.ru:<syntaxhighlight lang="rails">
require_relative 'config/environment'
</syntaxhighlight>

=== الملف config/environment.rb ===
هذا الملف ملفٌ مشتركٌ ومطلوبٌ من قبل <code>config.ru (rails server)‎</code> و Passenger. هنا تتقابل هاتان الطريقتان لتشغيل الخادم؛ كل شيء قبل هذه النقطة كان إعداد Rack و Rails.

يبدأ هذا الملف أوّلًا مع طلب config/application.rb:<syntaxhighlight lang="rails">
require_relative 'application'
</syntaxhighlight>

=== الملف config/application.rb ===
هذا يتطلّب الملف config/boot.rb:<syntaxhighlight lang="rails">
require_relative 'boot'

</syntaxhighlight>ولكن فقط إن لم يُطلب من قبل وهو الحال في <code>rails server</code> ولكن ليس مع Passenger.

ثم يبدأ المرح!

== تحميل ريلز ==
السطر التالي في config/application.rb هو:<syntaxhighlight lang="rails">
require 'rails/all'
</syntaxhighlight>

=== الملف railties/lib/rails/all.rb ===
هذا الملف مسؤول عن طلب كل الإطارات الفردية لريلز:<syntaxhighlight lang="rails">
require "rails"
 
%w(
  active_record/railtie
  action_controller/railtie
  action_view/railtie
  action_mailer/railtie
  active_job/railtie
  action_cable/engine
  active_storage/engine
  rails/test_unit/railtie
  sprockets/railtie
).each do |railtie|
  begin
    require railtie
  rescue LoadError
  end
end
</syntaxhighlight>تُحمّل هنا كل إطارات ريلز وبالتالي تُتاح للتطبيق. لن نتطرّق إلى تفاصيل ما يحدث داخل كل إطار من هذه الإطارات، ولكننا نشجّعك على تجربتها واستكشافها بنفسك.

ضع في اعتبارك حاليًّا أن جميع الوظائف الشائعة مثل [[Rails/engines|محرّكات ريلز]]، و<nowiki/>[[Rails/i18n|إعدادات I18n]] و<nowiki/>[[Rails/configuring|ضبط ريلز]] تُعرّف هنا.

=== الرجوع إلى الملف config/environment.rb ===
يعرّف باقي الملف config/application.rb الإعدادت لـ <code>Rails::Application</code> التي ستُستخدم بمجرّد اكتمال تهيئة التطبيق. عند انتهاء config/application.rb من تحميل ريلز وتحديد مجال اسم التطبيق، نعود إلى config/environment.rb. يُهيّئ التطبيق هنا مع <code>!Rails.application.initialize</code> المُعرّفة في rails/application.rb.

=== الملف railties/lib/rails/application.rb ===
يبدو التابع <code>initialize!‎</code> كالتالي:<syntaxhighlight lang="rails">
def initialize!(group=:default) #:nodoc:
  raise "Application has been already initialized." if @initialized
  run_initializers(group, self)
  @initialized = true
  self
end
</syntaxhighlight>يمكنك كما ترى تهيئة تطبيق ما مرّة واحدة فقط. تُشغّل المهيّئات من خلال التابع <code>run_initializers</code> التي تُعرّف في الملف railties/lib/rails/initializable.rb:<syntaxhighlight lang="rails">
def run_initializers(group=:default, *args)
  return if instance_variable_defined?(:@ran)
  initializers.tsort_each do |initializer|
    initializer.run(*args) if initializer.belongs_to?(group)
  end
  @ran = true
end
</syntaxhighlight>الشيفرة <code>run_initializers</code> بحد ذاتها صعبة. ما تفعله ريلز هنا هو عبور كل أسلاف (ancestors) الصنف باحثًا عن تلك التي تستجيب للتابع <code>initializers</code>. ترتب بعدها الأسلاف حسب الاسم وتشغّلها. على سبيل المثال، سيوفّر الصنف <code>Engine</code> جميع المحرّكات من خلال توفير التابع <code>initializers</code> بها.

يُعرّف الصنف <code>Rails::Application</code> - كما هو مُعرّف في الملف railties/lib/rails/application.rb - المهيّئات <code>railtie</code>، و <code>bootstrap</code>، و <code>railtie</code>، و <code>finisher</code>. يُعدّ المُهيّئ <code>bootstrap</code> التطبيق (مثلا بتهيئة المُسجل) بينما المهيئات <code>finisher</code> (مثل إنشاء مكدس برمجيّات وسيطة) آخر ما تُنفّذ. المهيّئات <code>railtie</code> هي المهيّئات التي عُرّفت على <code>Rails::Application</code> نفسه وتُشغّل بين برنامج <code>bootstrap</code> و <code>finishers</code>.

بعد الانتهاء من ذلك نعود إلى <code>Rack::Server</code>.

=== الملف Rack: lib/rack/server.rb ===
آخر مرة تركناه فيها كانت عند تعريف التابع <code>app</code>:<syntaxhighlight lang="rails">
def app
  @app ||= options[:builder] ? build_app_from_string : build_app_and_options_from_config
end
...
private
  def build_app_and_options_from_config
    if !::File.exist? options[:config]
      abort "configuration #{options[:config]} not found"
    end
 
    app, options = Rack::Builder.parse_file(self.options[:config], opt_parser)
    self.options.merge! options
    app
  end
 
  def build_app_from_string
    Rack::Builder.new_from_string(self.options[:builder])
  end
</syntaxhighlight>في هذه المرحلة، <code>app</code> هو تطبيق ريلز بحد ذاته (برنامج وسيط) وما سيحدث بعد ذلك هو استدعاء Rack لجميع البرامج الوسيطة (middlewares) المعطاة:<syntaxhighlight lang="rails">
def build_app(app)
  middleware[options[:environment]].reverse_each do |middleware|
    middleware = middleware.call(self) if middleware.respond_to?(:call)
    next unless middleware
    klass = middleware.shift
    app = klass.new(app, *middleware)
  end
  app
end
</syntaxhighlight>تذكّر أن <code>build_app</code> قد استدعي (من طرف <code>wrapped_app</code>) في السطر الأخير من <code>Server#start</code>. هذا شكله لما تركناه:<syntaxhighlight lang="rails">
server.run wrapped_app, options, &blk
</syntaxhighlight>يعتمد تنفيذ <code>server.run</code> في هذه المرحلة على الخادم الذي تستخدمه. إن كنت تستخدم Puma مثلًا، فإليك ما سيبدو عليه تابع run:<syntaxhighlight lang="rails">
...
DEFAULT_OPTIONS = {
  :Host => '0.0.0.0',
  :Port => 8080,
  :Threads => '0:16',
  :Verbose => false
}
 
def self.run(app, options = {})
  options = DEFAULT_OPTIONS.merge(options)
 
  if options[:Verbose]
    app = Rack::CommonLogger.new(app, STDOUT)
  end
 
  if options[:environment]
    ENV['RACK_ENV'] = options[:environment].to_s
  end
 
  server   = ::Puma::Server.new(app)
  min, max = options[:Threads].split(':', 2)
 
  puts "Puma #{::Puma::Const::PUMA_VERSION} starting..."
  puts "* Min threads: #{min}, max threads: #{max}"
  puts "* Environment: #{ENV['RACK_ENV']}"
  puts "* Listening on tcp://#{options[:Host]}:#{options[:Port]}"
 
  server.add_tcp_listener options[:Host], options[:Port]
  server.min_threads = min
  server.max_threads = max
  yield server if block_given?
 
  begin
    server.run.join
  rescue Interrupt
    puts "* Gracefully stopping, waiting for requests to finish"
    server.stop(true)
    puts "* Goodbye!"
  end
 
end

</syntaxhighlight>لن نتطرّق إلى تهيئة الخادم نفسه ولكن هذا آخر جزء من رحلتنا في عمليّة تهيئة ريلز.

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

== مصادر ==
* [https://guides.rubyonrails.org/initialization.html صفحة The Rails Initialization Processمن توثيق Ruby on Rails الرسمي].