Apache + FCGI + Ruby + ActiveRecord. Когда RoR много

rack, rake… всё смешалось.
зачем это вообще тут, для кого

Как масштабировать Ruby-приложения

Нет конечно. Пустой сервер на EventMachine года 2 назад тащил почти столько же, сколько и нода (~3k rps на ноуте). Рельсы, отдающие просто шаблон, ~400rps выдают.

REST API на Ruby на основе ActiveRecord для доступа к таблицам в базе данных

Enumerable#compact

REST API на Ruby на основе ActiveRecord для доступа к таблицам в базе данных

На POST /universal_api/kernel ответ будет, видимо, 500 и ошибка в логах `undefined method name 'column_names' for Kernel`.

Перевод: как gitLab использует unicorn и unicorn-worker-killer

Зачем еще один перевод? Еще остались пользователи юникорна, которые не знают про worker-killer? Нового ничего они не предлагают. Если пропустить через s/gitlab/other-unicorn-user/g, то всё так же останется правдой.

Рецепты тестирования Ruby и Rails приложений

Вместо такого можно писать:

sign_in { create(:user) }
let(:other_user) { create(:user) }
let!(:own_message) { create(:message, user: current_user) }
let!(:other_message) { create(:message, user: other_user) }

its(:body) { should contain other_message.text }
its(:body) { should contain own_message.text }

Т.е. в этом конкретном примере, мне кажется, нет необходимости в том, чтобы создавать сообщение другого пользователя внутри теста Проверять всё по-отдельности. Минусов от того, чтобы разнести проверки по разным тестам, я не вижу. Если же нужны большие интеграционные тесты каких-нибудь интерактивных фич, то пример из ссылки выше вроде подходит.
Напишите, пожалуйста, где можно посмотреть примеры на других языках того, что вы имеете в виду.

Рецепты тестирования Ruby и Rails приложений

`expect('').to be` проходит точно так же, как и `expect('').to be_truthy`. RSpec3

Рецепты тестирования Ruby и Rails приложений

1. нельзя. попробуйте.
2. should не рекомендуется в `x.should eq 5`, т.к. нужен манки-патч. `it { should… }` не требует, и его никто не запрещает. Смешивается, да, но плюсов по сравнению с `is_expected.to`, не вижу.
3. Разные вещи.
4. На 100+ тестах уже не удобно. Предпочитаю

# spec_helper.rb
  if config.files_to_run.one?
    config.default_formatter = 'doc'
  end

Рецепты тестирования Ruby и Rails приложений

Я надеюсь, все понимают, что будет делать `--require`, и какие от этого могут быть последствия. Конечно, в рельсовых приложениях бывают тесты, которые не зависят от application/rails. На моей памяти таких небольшое количество. Да, в некоторых случаях пользы от моего предложения не будет.

Добавлю только, что, если тесты не используют rails_helper, то, скорее всего, надо будет в каждом таком файле писать все require, самому поддерживать $: в актуальном состоянии в spec_helper. Ничего плохого в этом нет, просто об этом надо помнить.

Рецепты тестирования Ruby и Rails приложений

Какие именно сценарии интересуют? Самому пока не приходилось писать, но по-быстрому нагуглилось, что капибара, например, так может: blog.bruzilla.com/2012/04/10/using-multiple-capybara-sessions-in-rspec-request.html

Мне кажется, что с type: :request, тоже не должно быть проблем, но надо проверять.

Из Java в Scala: 7 причин для изучения нового языка

27.0 / 21
=> 1.2857…
«длиннее», судя по всему)

Новый GUI для Postgresql

Для сборки пакетов под все платформы разом можно посмотреть github.com/jordansissel/fpm
Сам не собирал, но вдруг пригодится.

Уязвимости веб-приложений: ситуация не улучшается

Да уж. Ладно еще может не все понимают, как XSS работает. Но про SQLI уже все слышали, знают чем опасно, и ничего сложного-то в защите нет. Все равно продолжают писать с уязвимостями.

Возможности PostgreSQL, которых нет в MySQL, и наоборот

В pg_hba можно правила для всех добавить, потом только CREATE USER будет достаточно:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

RailsStuff — набор для разработки на рельсах

Про ченджлог согласен. Но зачем так про амиго сразу :) Выше я писал:

При этом в RailsStuff собраны, конечно, не все модули, которые мы когда-либо использовали. Только те, которые мы использовали во многих проектах, которые часто добавлялись в первых комитах.

Всё, что вы перечислили, не вписывается в имеющийся набор, т.к. очень специализированное.

> тащить гору мусора тоже не хочется

Какие объективные причины для такой точки зрения? Я уверен, что и в рельсах и во многих других гемах мало кто использует абсолютно все функции/файлы, которые едут в геме.

RailsStuff — набор для разработки на рельсах

Попробую на статью набрать чего-нибудь интересного. Но сейчас всё кажется очень банальным.

Если ResourcesController будет быстро развиваться или окажется, что его лучше вынести отдельно — так и сделаем. То же самое и про все остальные части. Пока что, по-моему, это было бы не рационально — несколько гемов поддерживать требует больше времени, чем один. Гисты сложнее поддерживать в актуальном состоянии, и тесты к ним писать.

Скажите, что вас останавливало бы от использования одного только ResourcesController, установив весь набор? Все сделано на autoload, остальные файлы даже прочитаны не будут.

RailsStuff — набор для разработки на рельсах

Ну с вами всё понятно.

RailsStuff — набор для разработки на рельсах

Здравствуйте!

Компоненты действительно не связаны друг с другом. Почему они оказались вместе, я упомянул в начале поста. При этом в RailsStuff собраны, конечно, не все модули, которые мы когда-либо использовали. Только те, которые мы использовали во многих проектах, которые часто добавлялись в первых комитах. Чтобы не копить дубликаты файлов, вынесли их все в гем.

Относительно хэлпера перевода, я вижу несколько плюсов:
— Скорость работы вкупе с удобством использования. Для многих производительность в приложениях на рельсах — спорный вопрос, а жаль. Если это не аргумент, просто пропустите, пожалуйста. I18n.t — довольно сложный вызов и не самый быстрый. Время работы его растет, если используются фолбэки. Хранить перевод в локальных переменных, чтобы не переводить в циклах одно и то же — эффективнее, конечно, но больше писать надо, да и не все хотят.
— Один общий вариант использования. Не надо вспоминать, как надо переводить, нет длинных ключей, в которых можно ошибиться.
— Один общий способ организации переводов. Нет выбора, куда бы ещё положить перевод. Позволяет избежать повторений.

Свой хэлпер — это тоже хорошо. Просто тут он уже готовый. Только патчить I18n для этого не надо, имо :)

Apiway — новый способ клиент-серверной транспортировки данных

github.com/rails/actioncable не про это? Мне показалось, несколько похоже. Только у вас это контролерами называется, у них — каналами.

Авторизация в Redmine с другого сайта

Такое решение бессмысленно. Как «работает» xss токен:
— токен лежит в сессии (зашифрованный в куках или редисе, например);
— вы отдаете его только пользователю с этой сессией (это ключевой момент);
— при запросах от этого пользователя вы проверяете, совпадает ли токен из запроса с токеном из сессии.

В вашей реализации токен для всех один. Злоумышленнику нужно его 1 раз узнать, и он может его использовать, пока вы конфиг не поменяете, размещая на своих сайтах формы. Реферер-то вы просто проверяете на совпадение с текстом в токене (читай: сейчас у вас токен ничего не защищает).

Для чего нужен токен: чтобы от имени пользователя не слали запросы с других сайтов. Например, на сайте злоумышленника кнопка «скачать без смс и регистрации» отправляет аяксом POST http://your-domain/admin/destroy_all (ну или просто создания спам-поста от имени пользователя).

Если же вы уберете проверку токена для входа, то всё, что сможет сделать злоумышленник — залогинить пользователя. По-моему, это не страшно.

Если нужно запретить логин со сторонних сайтов, то нужно
— либо часто обновлять токен и подписывать его. Для этого на всех сайтах надо логику подписи делать, это не сложно, но без нее никак.
— либо просто использовать белый список рефереров.