💡 Инструкция: Выберите один ответ из пяти. Время — 55 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 4 тематических результатов и разбор всех ответов.
Вопрос 1 из 20
Проследите выполнение фрагмента. Какой результат верен для темы «Интерполяция»? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Интерполяция Копировать
# Проследите выполнение и выберите точный результат.
calculated = "total=#{2 * 3}"
literal = 'total=#{2 * 3}'
p [calculated, literal]
Два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash. Это объясняется тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Это объясняется тем, что методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Это объясняется тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Это объясняется тем, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Это объясняется тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Вопрос 3 из 20
Какое описание результата точно соответствует показанному коду «Кодировка»? Выберите связку, в которой верны и основной вывод, и его обоснование.
Ruby Ruby — Кодировка Копировать
# Проследите выполнение и выберите точный результат.
text = "é"
p text.encoding
p [text.length, text.bytesize, text.bytes]
p text.valid_encoding?
Строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа. Такой итог следует из правила: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash. Такой итог следует из правила: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа. Такой итог следует из правила: интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа. Такой итог следует из правила: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Такой итог следует из правила: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Вопрос 4 из 20
Как следует прочитать результат показанного примера «Изменение строк»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Изменение строк Копировать
# Проследите выполнение и выберите точный результат.
text = +'RUBY'
changed = text.upcase!
p [text, changed]
text << '!'
p text
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Механизм результата таков: интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления. Механизм результата таков: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash. Механизм результата таков: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Механизм результата таков: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`. Механизм результата таков: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Вопрос 5 из 20
Почему успешный пример ещё не доказывает надёжность решения «Интерполяция»? Ищите не знакомые слова, а технически непротиворечивую пару утверждений.
Ruby Ruby — Интерполяция Копировать
# Обычный запуск проходит. Найдите скрытый риск.
calculated = "total=#{2 * 3}"
literal = 'total=#{2 * 3}'
p [calculated, literal]
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. Причина — интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Причина — у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Причина — интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Причина — методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Причина — интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Вопрос 6 из 20
Какой дефект может проявиться на границе показанного сценария «Символы Symbol»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Символы Symbol Копировать
# Обычный запуск проходит. Найдите скрытый риск.
a = :ready
b = 'ready'.to_sym
p [a == b, a.object_id == b.object_id]
state = { ready: true }
p state[a]
Массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний. Этот риск связан с тем, что symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию.
Массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний. Этот риск связан с тем, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Этот риск связан с тем, что symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию.
Массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний. Этот риск связан с тем, что методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. Этот риск связан с тем, что symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию.
Вопрос 7 из 20
Где в показанном решении «Кодировка» скрыт дефект, который проявится не на каждом входе? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Кодировка Копировать
# Обычный запуск проходит. Найдите скрытый риск.
text = "é"
p text.encoding
p [text.length, text.bytesize, text.bytes]
p text.valid_encoding?
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Уязвимое место возникает потому, что методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Уязвимое место возникает потому, что интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. Уязвимое место возникает потому, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. Уязвимое место возникает потому, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. Уязвимое место возникает потому, что у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Вопрос 8 из 20
Какое допущение делает этот код по теме «Изменение строк» ненадёжным? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Изменение строк Копировать
# Обычный запуск проходит. Найдите скрытый риск.
text = +'RUBY'
changed = text.upcase!
p [text, changed]
text << '!'
p text
Ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность. К такому сбою приводит правило: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. К такому сбою приводит правило: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения. К такому сбою приводит правило: методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. К такому сбою приводит правило: у String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов.
Проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки. К такому сбою приводит правило: интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными.
Вопрос 9 из 20
Какой контракт нужно помнить при ревью кода по теме «Интерполяция»? Правильным считается только полностью согласованное утверждение.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Поэтому два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Вопрос 10 из 20
Какой принцип темы «Символы Symbol» переносится на другие примеры того же типа? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Из этого следует, что два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию. Из этого следует, что первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию. Из этого следует, что два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Из этого следует, что два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Symbol — неизменяемый идентификатор с содержимым имени; сравнение одинаковых символов даёт тот же объект, но преобразование пользовательских строк в символы не заменяет валидацию. Из этого следует, что для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Вопрос 11 из 20
Какой принцип темы «Кодировка» переносится на другие примеры того же типа? Смотрите на всю причинную связку, а не только на знакомую формулировку.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Наблюдаемое следствие: строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Наблюдаемое следствие: первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Наблюдаемое следствие: строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Наблюдаемое следствие: строка `é` в UTF-8 занимает два байта, но содержит один символ; `bytesize` и `length` возвращают разные числа.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Наблюдаемое следствие: два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Вопрос 12 из 20
Какое правило остаётся верным, даже если вход и порядок вызовов изменятся, в теме «Изменение строк»? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
У String есть кодировка, а совместимость операций зависит и от метки кодировки, и от фактических байтов. Именно поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Именно поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Именно поэтому два литерала `:ready` имеют одинаковый object_id и подходят как стабильные ключи Hash.
Интерполяция `#{...}` выполняется в строке с двойными кавычками, но остаётся буквальным текстом в строке с одинарными. Именно поэтому для уже заглавной строки `upcase!` возвращает nil, хотя сама строка остаётся `RUBY`.
Методы вроде `upcase` обычно создают новую строку, а `upcase!` меняет получателя и возвращает nil, если изменения не потребовались. Именно поэтому первая строка содержит вычисленное число 6, вторая — символы `#{2 * 3}` без вычисления.
Вопрос 13 из 20
Какой вариант решения «Интерполяция» останется понятным при сопровождении? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Интерполяция Копировать
# Выберите изменение, которое исправляет причину.
calculated = "total=#{2 * 3}"
literal = 'total=#{2 * 3}'
p [calculated, literal]
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Так закрывается риск: неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения.
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Так закрывается риск: проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки.
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Так закрывается риск: ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Так закрывается риск: неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения.
Не использовать возвращаемое значение bang-метода как признак валидности; сравнивать до/после или вызывать небанг-версию. Так закрывается риск: неверный выбор кавычек способен тихо отправить пользователю шаблон вместо значения, не вызывая исключения.
Вопрос 14 из 20
Какое исправление уменьшает риск, не скрывая исходное поведение «Символы Symbol»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Ruby Ruby — Символы Symbol Копировать
# Выберите изменение, которое исправляет причину.
a = :ready
b = 'ready'.to_sym
p [a == b, a.object_id == b.object_id]
state = { ready: true }
p state[a]
Выбирать тип кавычек по намерению и проверять итоговый текст, а не только отсутствие ошибки при его построении. Это изменение устраняет проблему: массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Это изменение устраняет проблему: проверка `if text.upcase!` смешивает факт изменения с фактом успеха и даёт ложную ветку для уже нормализованной строки.
Не использовать возвращаемое значение bang-метода как признак валидности; сравнивать до/после или вызывать небанг-версию. Это изменение устраняет проблему: массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Это изменение устраняет проблему: массовое символизирование внешних значений создаёт множество объектов Symbol и давит на память до их сборки, а главное — маскирует отсутствие перечня допустимых состояний.
Сопоставлять внешнюю строку с заранее известным набором символов, а неизвестные значения отвергать до бизнес-логики. Это изменение устраняет проблему: ограничение поля или обрезка по байтам может разрезать многобайтовый символ и породить недопустимую последовательность.