мсье, а после реилстуториал, какую книжку по рельсам стоит изучать? или уже можно пытаться самостоятельно познавтаь неизведанное?

Руби С. и др. - Rails 4. Гибкая разработка веб-приложений (Для профессионалов) - 2014

вот такую могу порекомендовать

там просто, по-русски и тестируют код

rails 5 уже

ну основные принципы же не сильно изменились

Руби С. и др. - Rails 4. Гибкая разработка веб-приложений (Для профессионалов) - 2014

Еще есть резон по ней учиться? 3 года прошло как то.

различия вполне можно посмотреть в http://guides.rubyonrails.org/upgrading_ruby_on_rails.html, кроме active job и action cable ничего существенного не добавилось, вроде

общий принцип (роуты/модели/вьюхи/контроллеры) тот же, главное понимать как эти вещи работают

(книгу не читал, имеется в виду изучение материала про rails4 в принципе)

Еще есть резон по ней учиться? 3 года прошло как то.

в пятых рельсах ничего революционно нового не ввели

ввели, но предыдущее мало задепрекейтилось в отличие от rails 3 -> 4

революционно нового ничего

action cable?

SSE уже давно было

в чем революция?

SSE?

и марсиане тутже anycable написали потому что actioncable желтая китайская поделка

маркетинговая фигня

SSE?

http://api.rubyonrails.org/classes/ActionController/Live/SSE.html

апи в какой версии почвилось?

официально в пятерке, но по сути можно было и в четверке проект покромсать

апи в какой версии почвилось?

в 2012 году

для поддоменов кто-нибудь apartment gem юзал? На сколько удобней чем обычные constraints?

Есть кто со Смоленска?

— О, Жакоб, мы отсюда не уедем никогда! Мы погибнем ! — Я все понял Жакоб, все пришельцы в Россию будут гибнуть под Смоленском.

Ребят, есть модель в которой есть enabled:bool, enable_at:time и disable_at:time, когда форма этой модели отправляеться, надо чтобы эти поля в контроллере цеплялись и отправлялись в очередь, так чтобы в когда настанет enable_at enabled становилось true, и когда настанет disable_at, enabled становилось false, при при этом надо так, что если форма занова отправлена была, старые джобы отменялись(или менялись) с новым значением из disable_at. может кто посоветует что юзать? или куда гуглить? подскажите плис.

какие требования к точности включения/выключения (секунда/минута/и пр.)?

час

А что мешает вместо enabled:bool проверять, попадает ли текущее время в диапазон?

enabled:bool нужна еще для того чтобы по ней возврощать модели рабочие

потомучто это поле можно еще в ручную менять, в форме

тогда проще всего по cron'у запускать скрипт/rake task, вестимо

а если надо перезаписать таск? ведь таких моделей много будет

ну как много, их будет в перделах 10-30

wtf 'перезаписать'?

ну напрмер отправии эту форму этой модели снова, там disable_at позже того что раньше был указан

надо поменять время выполнения такска в таком случае...

если требования к точности — час, есть смысл каждый час запускать скрипт.

ну ну в 1 раз отправлена форма c enable_at = 2017,03,01 15.00 а disable_at = 2017,03,07 15.00, а во второй раз (через день допустим), c enable_at = 2017,03,01 15.00 и disable_at = 2017,03,10 15.00, и изза этого надо чтобы таск с disable_at сраболтал не 2017,03,07 а 2017,03,10

таск не надо создавать для каждого изменения, таск должен обходить все модели и включать/выключать всё подряд по заданному условию

https://github.com/mperham/sidekiq/wiki/Scheduled-Job Не подойдет?

А насчет удалениея джобов - при создании он возвращает jid, по которому job-у можно удалять

при повтороной отправке

@silentshade спасибо, щас почитаю, выберу либо это либо крон который в каждый день выполняет таск и чекает диапозон

https://github.com/moove-it/sidekiq-scheduler

я бы сделал как ojab говорорит, только с постоянно запущенным демоном (иначе придётся проверять не запущен ли такой же ранее, а то можно сервер положить если тормозить начнёт)

я раньше юзал https://github.com/plashchynski/crono

врое норм работает, вроде несколько месяцев уже кртиться нормально

https://github.com/ondrejbartas/sidekiq-cron

ERROR: S client not available

я бы сделал как ojab говорорит, только с постоянно запущенным демоном (иначе придётся проверять не запущен ли такой же ранее, а то можно сервер положить если тормозить начнёт)

дублирующиеся таски ничего плохого не сделают + несложно исключаются/мониторятся, демон усложняет решение и добавляет ненужный state

если тормозить начнёт — не вижу разницы между скриптом и демоном

мой коллега на прошлой работе также говорил, повалил несколько раз сервак,я не теоретизирую большая часть команд вообще ничего не мониторит =) если начнёт тормозить, то демон будет ПОСЛЕДОВАТЕЛЬНО медленно делать. А крон задачи будут наслаиваться и жрать память

с sidekiq с одним воркером разницы не будет, но опять же надо контролировать что он запущен

Ну продакшен в целом всегда надо мониторить на кучу метрик, тут ничего нового.

причем чем дороже продакшен тем больше метрик собирается.

ну вы уверены что у человека который спрашивает совет всё именно так?

хочешь сказать за кроном не надо следить?

с такими вопросами лучше препройти в https://telegram.me/ruby_talks

ну вы уверены что у человека который спрашивает совет всё именно так?

это я про это

хочу сказать что крон опасен и неудобен в использовании и отладке и исходя их этого за ним надо следить внимательнее

как и за любыми фоновыми задачами

Если в бэкграунде ничего кроме этого больше процессится не будет, можно и по крону.. Из плюсов - нет оверхеда в виде воркера и редиса.. Из минусов - то что сказал @zloyrusskiy Я как-то пытался сделать такую систему столкнулся с тем что когда допустим процесс в кроне падает, pid остается, проверка есть ли процесс усложняется.. А если несколько разных задач, то это вообще превращается в адъ) В итоге предпочел очереди

Если в бэкграунде ничего кроме этого больше процессится не будет, можно и по крону.. Из плюсов - нет оверхеда в виде воркера и редиса.. Из минусов - то что сказал @zloyrusskiy Я как-то пытался сделать такую систему столкнулся с тем что когда допустим процесс в кроне падает, pid остается, проверка есть ли процесс усложняется.. А если несколько разных задач, то это вообще превращается в адъ) В итоге предпочел очереди

а зачем проверять pid-файлы, если хватает flock?

как и за любыми фоновыми задачами

фоновые задачи реже приводят к 100500 процессам и коллапсу, если она разрастётся её OOM Killer прибьёт и если правильно запускаете она перезапуститься и всё будет работать

то есть в слабых командах я видел что фоновые задачи крешились и не запускались

и крон задачи которые выжирали память и вводили сервер в паралич

я не говорю что ими не нужно пользоваться, просто они обманчиво просты с виду

systemd пацаны, есть опция - ран always и ничего не надо следить

ага, и деплоить "удобно"

а зачем проверять pid-файлы, если хватает flock?

можно и так

ojab Честно говря не помню уже почему, давно это было.. скорее всего это был один файл, но с разными параметрами, но более вероятно я просто тогда не знал про flock )) Я и сейчас про него не подумал описывая тот кейс

systemd пацаны, есть опция - ран always и ничего не надо следить

я тоже запускал через него в последнее время