Gems, Bundler и зависимости — бесплатный тест онлайн

Вопрос 1 из 25

Какое описание результата точно соответствует показанному коду «Описание зависимостей в Gemfile»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.

# Проследите выполнение и выберите точный результат.
source 'https://rubygems.org'

gem 'rack', '~> 3.1'
group :test do
  gem 'rspec'
end

Файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Это объясняется тем, что Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Это объясняется тем, что Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Это объясняется тем, что Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Это объясняется тем, что gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Это объясняется тем, что ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска.

Вопрос 2 из 25

Проследите выполнение фрагмента. Какой результат верен для темы «Lock-файл»? Правильным считается только полностью согласованное утверждение.

# Проследите выполнение и выберите точный результат.
lock = <<~LOCK
  GEM
    specs:
      rack (3.1.8)
  DEPENDENCIES
    rack (~> 3.1)
  BUNDLED WITH
     2.6.2
LOCK
puts lock

Файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Причина такого результата: Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Причина такого результата: зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Причина такого результата: Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Причина такого результата: Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Причина такого результата: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет.

Вопрос 3 из 25

Какой вариант верно описывает состояние объектов после выполнения кода «Семантическое версионирование»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.

# Проследите выполнение и выберите точный результат.
require 'rubygems'
req = Gem::Requirement.new('~> 2.3.1')
%w[2.3.9 2.4.0 3.0.0].each do |v|
  p [v, req.satisfied_by?(Gem::Version.new(v))]
end

Спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю. Такой итог следует из правила: ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет. Такой итог следует из правила: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет. Такой итог следует из правила: зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет. Такой итог следует из правила: ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Такой итог следует из правила: ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска.

Вопрос 4 из 25

Что произойдёт после последней строки в примере по теме «Публикация gem»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.

# Проследите выполнение и выберите точный результат.
Gem::Specification.new do |s|
  s.name = 'tiny_report'
  s.version = '1.2.0'
  s.files = Dir['lib/**/*.rb', 'README.md']
  s.required_ruby_version = '>= 3.2'
  s.add_dependency 'json', '>= 2.7'
end

Спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю. Механизм результата таков: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю. Механизм результата таков: зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю. Механизм результата таков: ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет. Механизм результата таков: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Механизм результата таков: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет.

Вопрос 5 из 25

Как следует прочитать результат показанного примера «Читаемость решения»? Нужен вариант без логического разрыва между первой и второй частью.

# Проследите выполнение и выберите точный результат.
# lib/report.rb
require 'json'

class Report
  def dump(data)
    JSON.generate(data)
  end
end
p Report.new.dump(ok: true)

`bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Наблюдение согласуется с тем, что зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Наблюдение согласуется с тем, что зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Наблюдение согласуется с тем, что зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Наблюдение согласуется с тем, что gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Наблюдение согласуется с тем, что Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку.

Вопрос 6 из 25

Какой рабочий сбой вероятнее всего связан именно с механизмом «Описание зависимостей в Gemfile»? Нужен вариант без логического разрыва между первой и второй частью.

# Обычный запуск проходит. Найдите скрытый риск.
source 'https://rubygems.org'

gem 'rack', '~> 3.1'
group :test do
  gem 'rspec'
end

Широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения. Причина — ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения. Причина — Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. Широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения. Причина — gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Причина — Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. Код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Причина — Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным.

Вопрос 7 из 25

Какой дефект может проявиться на границе показанного сценария «Lock-файл»? Проверьте обе половины ответа: частично верный вариант остаётся неверным.

# Обычный запуск проходит. Найдите скрытый риск.
lock = <<~LOCK
  GEM
    specs:
      rack (3.1.8)
  DEPENDENCIES
    rack (~> 3.1)
  BUNDLED WITH
     2.6.2
LOCK
puts lock

Удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Этот риск связан с тем, что зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Этот риск связан с тем, что Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Этот риск связан с тем, что gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Этот риск связан с тем, что Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Этот риск связан с тем, что Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку.

Вопрос 8 из 25

Какое допущение делает этот код по теме «Семантическое версионирование» ненадёжным? Выберите связку, в которой верны и основной вывод, и его обоснование.

# Обычный запуск проходит. Найдите скрытый риск.
require 'rubygems'
req = Gem::Requirement.new('~> 2.3.1')
%w[2.3.9 2.4.0 3.0.0].each do |v|
  p [v, req.satisfied_by?(Gem::Version.new(v))]
end

Предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Уязвимое место возникает потому, что gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Уязвимое место возникает потому, что ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Уязвимое место возникает потому, что зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения. Уязвимое место возникает потому, что ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Уязвимое место возникает потому, что ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска.

Вопрос 9 из 25

Базовый пример выглядит корректно. Что всё же нарушает контракт в блоке «Публикация gem»? В правильном ответе вторая часть действительно объясняет или проверяет первую.

# Обычный запуск проходит. Найдите скрытый риск.
Gem::Specification.new do |s|
  s.name = 'tiny_report'
  s.version = '1.2.0'
  s.files = Dir['lib/**/*.rb', 'README.md']
  s.required_ruby_version = '>= 3.2'
  s.add_dependency 'json', '>= 2.7'
end

Код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. К такому сбою приводит правило: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Шаблон `git ls-files` без проверки может включить тестовые ключи, временные данные или файлы, которые отсутствуют в опубликованном архиве сборочной среды. К такому сбою приводит правило: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Шаблон `git ls-files` без проверки может включить тестовые ключи, временные данные или файлы, которые отсутствуют в опубликованном архиве сборочной среды. К такому сбою приводит правило: ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. К такому сбою приводит правило: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Шаблон `git ls-files` без проверки может включить тестовые ключи, временные данные или файлы, которые отсутствуют в опубликованном архиве сборочной среды. К такому сбою приводит правило: зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет.

Вопрос 10 из 25

Что может сломаться при переносе этого решения «Читаемость решения» в рабочую систему? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.

# Обычный запуск проходит. Найдите скрытый риск.
# lib/report.rb
require 'json'

class Report
  def dump(data)
    JSON.generate(data)
  end
end
p Report.new.dump(ok: true)

Код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Источник риска: gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Источник риска: зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Источник риска: Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Источник риска: зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Источник риска: зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет.

Вопрос 11 из 25

Какое правило остаётся верным, даже если вход и порядок вызовов изменятся, в теме «Описание зависимостей в Gemfile»? В правильном ответе вторая часть действительно объясняет или проверяет первую.

Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. Поэтому файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. Поэтому Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Gemfile описывает источники и допустимые версии прямых зависимостей, а группы управляют контекстом установки, но не делают код автоматически недоступным. Поэтому `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Поэтому Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Поэтому Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие.

Вопрос 12 из 25

Какой механизм объясняет и обычный, и граничный сценарий «Lock-файл»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.

Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Из этого следует, что `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Из этого следует, что файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Из этого следует, что `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Из этого следует, что `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Из этого следует, что Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие.

Вопрос 13 из 25

На какой контракт языка или библиотеки опирается результат блока «Семантическое версионирование»? Смотрите на всю причинную связку, а не только на знакомую формулировку.

Зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Наблюдаемое следствие: версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет. Gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Наблюдаемое следствие: версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет. Ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Наблюдаемое следствие: файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Наблюдаемое следствие: спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю. Ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Наблюдаемое следствие: версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет.

Вопрос 14 из 25

Как сформулировать правило блока «Публикация gem» без лишних обещаний? Выберите связку, в которой верны и основной вывод, и его обоснование.

Gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Именно поэтому спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю. Зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Именно поэтому спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю. Gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Именно поэтому файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Именно поэтому версия 2.3.9 удовлетворяет `~> 2.3.1`, а 2.4.0 — уже нет. Ограничение `~> 2.3.1` допускает версии от 2.3.1 до, но не включая, 2.4.0; `>=` само по себе не защищает от несовместимого основного выпуска. Именно поэтому спецификация создаёт gem с явной версией Ruby и runtime-зависимостью, доступной потребителю.

Вопрос 15 из 25

Какой принцип темы «Читаемость решения» переносится на другие примеры того же типа? Оценивайте ответ целиком: обе части утверждения должны быть точными.

Зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Это правило даёт такой результат: `bundle install` использует зафиксированные версии, пока ограничения позволяют это, вместо выбора каждого свежего выпуска заново. Gemspec должен перечислять файлы, метаданные, требуемую версию Ruby и зависимости; секреты и сборочные остатки не должны попадать в пакет. Это правило даёт такой результат: файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Это правило даёт такой результат: Gemfile объявляет `rack` прямой зависимостью и ограничивает допустимые версии диапазоном `~> 3.1`; Bundler затем разрешает это условие. Gemfile.lock фиксирует полное разрешённое дерево версий и платформ; для приложения его обычно коммитят, чтобы повторить установку. Это правило даёт такой результат: файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше. Зависимость должна быть видна там, где используется: прямой require и декларация лучше случайной доступности через транзитивный пакет. Это правило даёт такой результат: файл явно подключает JSON до вызова `JSON.generate`, поэтому работает независимо от того, загрузил ли библиотеку кто-то раньше.

Вопрос 16 из 25

Какой вариант решения «Описание зависимостей в Gemfile» останется понятным при сопровождении? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.

# Выберите изменение, которое исправляет причину.
source 'https://rubygems.org'

gem 'rack', '~> 3.1'
group :test do
  gem 'rspec'
end

Сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Так закрывается риск: широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения. Ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Так закрывается риск: предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Так закрывается риск: широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения. Ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Так закрывается риск: код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Так закрывается риск: широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения.

Вопрос 17 из 25

Какой рефакторинг делает контракт блока «Lock-файл» явным и проверяемым? Нужен вариант без логического разрыва между первой и второй частью.

# Выберите изменение, которое исправляет причину.
lock = <<~LOCK
  GEM
    specs:
      rack (3.1.8)
  DEPENDENCIES
    rack (~> 3.1)
  BUNDLED WITH
     2.6.2
LOCK
puts lock

Ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Это изменение устраняет проблему: удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Это изменение устраняет проблему: удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Это изменение устраняет проблему: код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Это изменение устраняет проблему: предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Это изменение устраняет проблему: удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины.

Вопрос 18 из 25

Что следует изменить в решении «Семантическое версионирование», чтобы закрыть исходный риск? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.

# Выберите изменение, которое исправляет причину.
require 'rubygems'
req = Gem::Requirement.new('~> 2.3.1')
%w[2.3.9 2.4.0 3.0.0].each do |v|
  p [v, req.satisfied_by?(Gem::Version.new(v))]
end

Сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Такая правка нужна из-за риска: код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Такая правка нужна из-за риска: предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Такая правка нужна из-за риска: предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Такая правка нужна из-за риска: предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Такая правка нужна из-за риска: широкое или отсутствующее ограничение позволяет следующей установке получить несовместимый основной выпуск без изменения приложения.

Вопрос 19 из 25

Как исправить реализацию «Публикация gem» без новой скрытой зависимости? Проверьте обе половины ответа: частично верный вариант остаётся неверным.

# Выберите изменение, которое исправляет причину.
Gem::Specification.new do |s|
  s.name = 'tiny_report'
  s.version = '1.2.0'
  s.files = Dir['lib/**/*.rb', 'README.md']
  s.required_ruby_version = '>= 3.2'
  s.add_dependency 'json', '>= 2.7'
end

Перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Решение адресует следующий дефект: код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Решение адресует следующий дефект: удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Решение адресует следующий дефект: шаблон `git ls-files` без проверки может включить тестовые ключи, временные данные или файлы, которые отсутствуют в опубликованном архиве сборочной среды. Обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Решение адресует следующий дефект: шаблон `git ls-files` без проверки может включить тестовые ключи, временные данные или файлы, которые отсутствуют в опубликованном архиве сборочной среды. Перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Решение адресует следующий дефект: шаблон `git ls-files` без проверки может включить тестовые ключи, временные данные или файлы, которые отсутствуют в опубликованном архиве сборочной среды.

Вопрос 20 из 25

Какой рефакторинг делает контракт блока «Читаемость решения» явным и проверяемым? Правильным считается только полностью согласованное утверждение.

Перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Именно эта мера закрывает риск: код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Именно эта мера закрывает риск: удаление lock-файла во время аварийного развёртывания одновременно меняет множество транзитивных зависимостей и затрудняет поиск причины. Запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Именно эта мера закрывает риск: предположение, что любой gem строго соблюдает Semantic Versioning, делает даже формально безопасное обновление потенциально ломающим. Запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Именно эта мера закрывает риск: код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require. Обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Именно эта мера закрывает риск: код проходит в полном приложении, но падает в отдельном тесте или после удаления соседнего gem, если полагается на транзитивный require.

Вопрос 21 из 25

Что следует добавить в набор проверок по теме «Описание зависимостей в Gemfile», чтобы поймать редкий отказ? В правильном ответе вторая часть действительно объясняет или проверяет первую.

Проверить yanked-релиз и повторную публикацию: номер уже опубликованной версии нельзя безопасно переиспользовать. Этот сценарий проверяет исправление: ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Проверить, действительно ли рабочая среда устанавливает нужные группы; `require` пакета зависит от настройки Bundler и кода. Этот сценарий проверяет исправление: обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Проверить, действительно ли рабочая среда устанавливает нужные группы; `require` пакета зависит от настройки Bundler и кода. Этот сценарий проверяет исправление: ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Проверить, действительно ли рабочая среда устанавливает нужные группы; `require` пакета зависит от настройки Bundler и кода. Этот сценарий проверяет исправление: сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Проверить предварительные версии: правила сравнения `2.4.0.pre` отличаются от бытового представления «почти 2.4». Этот сценарий проверяет исправление: ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке.

Вопрос 22 из 25

Какой случай покажет, что исправление «Lock-файл» не держится на удачном входе? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.

Проверить автозагрузку Rails и обычный запуск Ruby: наличие константы в одном режиме не гарантирует её в другом. Так проверяется решение: обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Проверить yanked-релиз и повторную публикацию: номер уже опубликованной версии нельзя безопасно переиспользовать. Так проверяется решение: обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Проверить установку на каждой целевой платформе: lock-файл может содержать разные варианты нативного gem. Так проверяется решение: ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке. Проверить установку на каждой целевой платформе: lock-файл может содержать разные варианты нативного gem. Так проверяется решение: обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Проверить установку на каждой целевой платформе: lock-файл может содержать разные варианты нативного gem. Так проверяется решение: запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде.

Вопрос 23 из 25

Чем дополнить базовый тест, чтобы проверить ограничение темы «Семантическое версионирование»? Смотрите на всю причинную связку, а не только на знакомую формулировку.

Проверить предварительные версии: правила сравнения `2.4.0.pre` отличаются от бытового представления «почти 2.4». Проверка относится к изменению: сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Проверить yanked-релиз и повторную публикацию: номер уже опубликованной версии нельзя безопасно переиспользовать. Проверка относится к изменению: сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Проверить предварительные версии: правила сравнения `2.4.0.pre` отличаются от бытового представления «почти 2.4». Проверка относится к изменению: обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Проверить автозагрузку Rails и обычный запуск Ruby: наличие константы в одном режиме не гарантирует её в другом. Проверка относится к изменению: сочетать разумный диапазон с автоматическими тестами и журналом изменений конкретного пакета, а не считать оператор гарантией совместимости. Проверить предварительные версии: правила сравнения `2.4.0.pre` отличаются от бытового представления «почти 2.4». Проверка относится к изменению: ограничивать прямые зависимости осмысленно, регулярно обновлять их отдельными изменениями и проверять приложение на чистой установке.

Вопрос 24 из 25

Какой регрессионный пример обнаружит ошибочное обобщение в теме «Публикация gem»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.

Проверить автозагрузку Rails и обычный запуск Ruby: наличие константы в одном режиме не гарантирует её в другом. Сценарий подтверждает надёжность решения: перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Проверить yanked-релиз и повторную публикацию: номер уже опубликованной версии нельзя безопасно переиспользовать. Сценарий подтверждает надёжность решения: перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Проверить предварительные версии: правила сравнения `2.4.0.pre` отличаются от бытового представления «почти 2.4». Сценарий подтверждает надёжность решения: перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Проверить yanked-релиз и повторную публикацию: номер уже опубликованной версии нельзя безопасно переиспользовать. Сценарий подтверждает надёжность решения: запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Проверить yanked-релиз и повторную публикацию: номер уже опубликованной версии нельзя безопасно переиспользовать. Сценарий подтверждает надёжность решения: обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ.

Вопрос 25 из 25

Что нужно воспроизвести отдельно перед выпуском изменения «Читаемость решения»? Оценивайте ответ целиком: обе части утверждения должны быть точными.

Проверить автозагрузку Rails и обычный запуск Ruby: наличие константы в одном режиме не гарантирует её в другом. На этой границе проверяется мера: обновлять одну зависимость целевой командой и просматривать дифф lock-файла, включая изменения транзитивных пакетов и платформ. Проверить предварительные версии: правила сравнения `2.4.0.pre` отличаются от бытового представления «почти 2.4». На этой границе проверяется мера: запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Проверить автозагрузку Rails и обычный запуск Ruby: наличие константы в одном режиме не гарантирует её в другом. На этой границе проверяется мера: перед публикацией распаковывать собранный gem, проверять список файлов и запускать тест установки в пустом окружении. Проверить автозагрузку Rails и обычный запуск Ruby: наличие константы в одном режиме не гарантирует её в другом. На этой границе проверяется мера: запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде. Проверить yanked-релиз и повторную публикацию: номер уже опубликованной версии нельзя безопасно переиспользовать. На этой границе проверяется мера: запускать тесты каждого компонента в минимальном наборе зависимостей и явно объявлять всё, что требуется в рабочем коде.