Comments 30
Отправка файла пользователю — обычно статические файлы передаются по прямому УРЛу в обход рельсового приложения. Тем не менее в ряде ситуаций может быть полезно спрятать расположение файла, особенно если вы посылаете что-либо ценное, наподобии е-книги. Может также требоваться ограничить посылку файлов только залогиненным пользователям. Проблему решает send_file. Файлы передаются по 4096 байтов, так что даже большие файлы систему не затормозят.
К сожалению, это неправда. Когда метод send_file используется в приложении Rails, которое работает под Mongrel (под mod_rails не проверял еще), весь файл считывается-таки в память! Поэтому использование send_file для отправки больших файлов приведет только к головной боли.
Запуск длинных процессов отдельно в фоне — есть небольшой фреймворк BackgrounDRbот Эзры Зигмунтовича (Ezra Zygmuntovich), который запускается в виде демона и принимает задачи от рельсового приложения, и выполняет их независимо. Мощная вещь, помогает в рассылке писем, получении УРЛов, и прочего, что может затормозить время выполнения запроса основного приложения. Демо-таск увеличивает переменную на 1, после чего делает sleep на 1 секунду. Далее делаем рельсовый метод, который опрашивает эту переменную, и чувствуем разницу.
Не спорю, вещь хорошая. Но это хорошо, если память сервера позволяет крутится еще рубишному демону. Иногда cron задача и rake task бывает достаточно.
Выборка элементов страницы через RJS — поменять элемент в RJS нетрудно, но что если мы не знаем, какой именно элемент надо менять, и хотели бы адресоваться через CSS-запрос? Это возможно с методом select. Например, page.select('#items li').each { |item| item.hide }. Мощная штука!
От RJS начинают уже давно отказываться. Он не гибок.
Проверка существования — при выполнении Model.find(id) мы получим исключение, если элемента «id» не нашлось. Чтобы это избежать, сперва выполняем Model.exists?(id), чтобы узнать, есть ли такой.
Исключение будет только на dev-среде. В prod-среде вернет nil.
0
Исключение будет только на dev-среде. В prod-среде вернет nil.
Неправда.
+1
Кто от RJS отказался, вы? Чем оне не гибок? Просветите.
Рык создаёт новый инстанс рельсов, за его использование в таких ситуациях надо руки отрывать. DJ — наше всё, а лучше AMQP
Model.find(id) всегда бросается исключениями.
Рык создаёт новый инстанс рельсов, за его использование в таких ситуациях надо руки отрывать. DJ — наше всё, а лучше AMQP
Model.find(id) всегда бросается исключениями.
0
RJS вполне гибок, просто «немодный». Сейчас модно делать «ненавязчивый» Javascript, поэтому, в частности, jQuery-гикам RJS кажется некрасивым.
0
Про ненавязчивый яваскрипт я понимаю, но мы же не о нём говорим, а об RJS, а это несколько другое.
Я так понимаю, что ненавязчивый яваскрипты — это когда для всех похожих аякс запросов создаётся функция, а хелпер — link_to_function вместо link_to_remote, или вообще без хелперов, сам главный яваскрипт обработчики вешает.
Но без RJS в любом случае неудобно, для сложных систем можно написать спецклассы, которые бы кушали json, к примеру, но в любом случае, это либо эвал приходящего кода с вызовом функции (тот же rjs), либо навешивание кучи уродливых коллбэков на каждый аякс чих.
RJS гибче и красивее, имхо.
Я так понимаю, что ненавязчивый яваскрипты — это когда для всех похожих аякс запросов создаётся функция, а хелпер — link_to_function вместо link_to_remote, или вообще без хелперов, сам главный яваскрипт обработчики вешает.
Но без RJS в любом случае неудобно, для сложных систем можно написать спецклассы, которые бы кушали json, к примеру, но в любом случае, это либо эвал приходящего кода с вызовом функции (тот же rjs), либо навешивание кучи уродливых коллбэков на каждый аякс чих.
RJS гибче и красивее, имхо.
0
Не вижу ничего плохого в исключениях, их для того и придумали) И руки нужно отрывать за их неиспользование:)
0
ну если rake задача из рельсового окружения то она сожрет куда больше памяти чем демон.
0
можно искать так — Model.find_by_id(id) тогда вернет nil
0
Спасибо за перевод, до этого использовал только тестирование роутов.
+1
bubuq спасибо конечно за перевод, но обрати пожалуйста на дату написания статьи — «July 8th, 2006» множество советов уже устарели, и могут только нанести вред новичкам
+7
Мои варианты:
>acts_as_nested_set
awesome_nested_set
>Превращение массивов в предложения
script/plugin install git://github.com/yaroslav/russian.git
«Peter, Fred и Chris» # запятая перед «и» или «and» не ставится в обоих случаях!
Тоже самое относится и к «Числовые хелперы для частых задач» — GB -> ГБ
>Запуск длинных процессов отдельно в фоне
Приведённый способ крайне нерационален. Я использую aasm и spawn. Куда менее требовательно к ресурсам, чем sleep + переменная.
>acts_as_nested_set
awesome_nested_set
>Превращение массивов в предложения
script/plugin install git://github.com/yaroslav/russian.git
«Peter, Fred и Chris» # запятая перед «и» или «and» не ставится в обоих случаях!
Тоже самое относится и к «Числовые хелперы для частых задач» — GB -> ГБ
>Запуск длинных процессов отдельно в фоне
Приведённый способ крайне нерационален. Я использую aasm и spawn. Куда менее требовательно к ресурсам, чем sleep + переменная.
0
Запятая перед «and» в перечислении из трёх и более элементов, конечно же, ставится.
+1
Да, в английском ставится. Пардон.
>> %w{ниф-ниф наф-наф нуф-нуф серый_волк}.to_sentence
=> «ниф-ниф, наф-наф, нуф-нуф и серый_волк»
>> %w{ниф-ниф наф-наф нуф-нуф серый_волк}.to_sentence
=> «ниф-ниф, наф-наф, нуф-нуф, and серый_волк»
>> %w{ниф-ниф наф-наф нуф-нуф серый_волк}.to_sentence
=> «ниф-ниф, наф-наф, нуф-нуф и серый_волк»
>> %w{ниф-ниф наф-наф нуф-нуф серый_волк}.to_sentence
=> «ниф-ниф, наф-наф, нуф-нуф, and серый_волк»
0
0
А для
apidock.com/rails/ActiveSupport/Inflector/parameterize
to_param
в свежих рельсах есть String#parameterize
:apidock.com/rails/ActiveSupport/Inflector/parameterize
0
Дальнейшее повышение производительности — по умолчанию рельсы записывают сессии на локальную файловую систему.
Не верно! в CookieStore.
0
Устаревшее:
Локальный бенчмаркинг — Rack::Bug.
github.com/brynary/rack-bug
Фоновое выполнение — Delayed Job или bj.
github.com/collectiveidea/delayed_job
github.com/github/bj/
Локальный бенчмаркинг — Rack::Bug.
github.com/brynary/rack-bug
Фоновое выполнение — Delayed Job или bj.
github.com/collectiveidea/delayed_job
github.com/github/bj/
0
Еще, на грани с фактической ошибкой: «общий»
Вообще, to_yaml нужен в основном для сериализации, и «наружу» его отдавать смысла очень мало.
Проверку валидности XHTML можно делать, например, если тестировать приложение с помощью Cucumber — парсер nokogiri, который будет использоваться, будет страшно ругаться на незакрытые теги и прочие вещи (если вы еще используете ERB, а не перешли на HAML)
to_yaml
не является рельсовым методом (методом ActiveSupport
), а значит, на него не действуют соглашения методов to_xml
и to_json
(:only
, :include
) и прочие.Вообще, to_yaml нужен в основном для сериализации, и «наружу» его отдавать смысла очень мало.
Проверку валидности XHTML можно делать, например, если тестировать приложение с помощью Cucumber — парсер nokogiri, который будет использоваться, будет страшно ругаться на незакрытые теги и прочие вещи (если вы еще используете ERB, а не перешли на HAML)
+1
По поводу send_file — лучше проанализировать, на каком сервере будет работать production и отправлять заголовок либо X-Sendfile для Apache2, либо X-Accel-Recirect для nginx. Ну в development будет send_file, да. Был какой-то плагин даже для этого.
На одном проекте выставление заголовка для nginx позволило сменить состояние сервера с «пипец какой загруженнй» до «сервак то вообщем простаивает».
На одном проекте выставление заголовка для nginx позволило сменить состояние сервера с «пипец какой загруженнй» до «сервак то вообщем простаивает».
0
UFO just landed and posted this here
Sign up to leave a comment.
Articles
Change theme settings
19 необщеизвестных приёмов