Я прекрасно понимаю, что не все пользуются Гитом. Но целевая аудитория статьи – именно пользователи Гита, поэтому уточнения только поломали бы вступление.
Однако прочитав ваш комментарий, стало интересно узнать о таком подходе промышленной и внутренней разработки. Что значит «вы просто блокируете код/интерфейсы и пишете»? И почему «новая значительная версия» не может быть добавлена при использовании СКВ? И вот тезис про «некогда» заниматься работой с СКВ странный.
Очень спорный «стандарт», использовать кастомизируемый инструмент, но при этом завязываться на чужой набор кастомизаций.
В этом и заключается стандарт – кастомизации у всех одни и те же, а не самописные костыли.
Я был удивлён, когда понял, что немногие используют эти сокращения, хоть и работают через Zsh. Поэтому в форме обучающей статьи решил показать на примерах как выглядит такой подход, и рассказать чем он удобен.
Спасибо, я понял вашу позицию. Если станет понятно, что большинству так читать неудобно, то будем оставлять названия на оригинале. Пока же мы имеем противоположное мнение.
CRUD – аббревиатура, не переводим. Ecto, ActiveRecord – технически специфические термины, названия библиотек, не переводим. Такие названия специально выделяем тегом < code >< /code >. И хоть дизайн Хабра не выделяет их в рамочку, как это принято, но хотя бы применяет моноширинный шрифт.
В статье я не вижу противоречий. Для периодического запуска задач на Руби, в любом случае, понадобится некая «cron-like» библиотека, это не обязательно сам Юниксовский `cron`. Вы далее в своём комментарии правильно уточняете, что эту задачу можно решить и через «отложенные задачи» и «планировщики к ним».
Теперь по поводу старта процесса. Возьмём для примера сервер приложения `Unicorn`. Он создаёт постоянно висящий мастер-процесс и на каждый запрос действительно форкает дочерние. Конечно же само приложение не перезапускается для каждого клиента :) В целом в этой фразе нет противоречия.
Потому что это русский язык, а на русском мы говорим «Руби», «рубист», «хочу писать на Эликсире». А по поводу того, что в половине мест написано на английском: проверил и оказалось, что ОДИН раз в статье действительно написано «Ruby», поправил. Но зачем же так передёргивать?
Ресурсы могут дублироваться в этом файле в зависимости от задач. В данном случае у нас 3 задачи:
выводить список постов
работать с постами пользователя
работать с комментариями постов
Поэтому нам нужно описать 3 раздельных группы ресурсов:
scope "/", Pxblog do
pipe_through :browser # Use the default browser stack
get "/", PageController, :index
resources "/users", UserController do
# Как раз тут создаётся хелпер user_post_path
resources "/posts", PostController
end
resources "/posts", PostController, only: [] do
resources "/comments", CommentController, only: [:create, :delete, :update]
end
resources "/sessions", SessionController, only: [:new, :create, :delete]
end
Зависимости и прибиты гвоздями в файле `mix.lock`.
Такая стрелочка `~>` помогает легче обновлять библиотеку вручную, непременно с помощью ручного ввода команды на обновление.
А изменения `1.3` не должны убивать приложения на `1.2`, как можно увидеть – изменения вынесены отдельно и являются в некотором роде экспериментальными.
tenhi_shadow
Что-то я не понял примера с
git add звёздочка. Написатьgaa– вот это удобно.Разве цвет не по умолчанию прописан в конфиге Гита? Нет никакой необходимости в этом ключе
git diff --color.З.Ы. Промахнулся веткой для ответа.
Однако прочитав ваш комментарий, стало интересно узнать о таком подходе промышленной и внутренней разработки. Что значит «вы просто блокируете код/интерфейсы и пишете»? И почему «новая значительная версия» не может быть добавлена при использовании СКВ? И вот тезис про «некогда» заниматься работой с СКВ странный.
В этом и заключается стандарт – кастомизации у всех одни и те же, а не самописные костыли.
Я был удивлён, когда понял, что немногие используют эти сокращения, хоть и работают через Zsh. Поэтому в форме обучающей статьи решил показать на примерах как выглядит такой подход, и рассказать чем он удобен.
Вообще в качестве вводного курса можно пройти серии статей «Делаем блог на Фениксе» и «Клон Трелло на Фениксе и Реакте», а затем уже искать ответы на вопросы в официальной документации.
Спасибо, я понял вашу позицию. Если станет понятно, что большинству так читать неудобно, то будем оставлять названия на оригинале. Пока же мы имеем противоположное мнение.
CRUD– аббревиатура, не переводим.Ecto,ActiveRecord– технически специфические термины, названия библиотек, не переводим. Такие названия специально выделяем тегом< code >< /code >. И хоть дизайн Хабра не выделяет их в рамочку, как это принято, но хотя бы применяет моноширинный шрифт.В статье я не вижу противоречий. Для периодического запуска задач на Руби, в любом случае, понадобится некая «cron-like» библиотека, это не обязательно сам Юниксовский `cron`. Вы далее в своём комментарии правильно уточняете, что эту задачу можно решить и через «отложенные задачи» и «планировщики к ним».
Теперь по поводу старта процесса. Возьмём для примера сервер приложения `Unicorn`. Он создаёт постоянно висящий мастер-процесс и на каждый запрос действительно форкает дочерние. Конечно же само приложение не перезапускается для каждого клиента :) В целом в этой фразе нет противоречия.
Вам нужно немного изменить роуты.
Ресурсы могут дублироваться в этом файле в зависимости от задач. В данном случае у нас 3 задачи:
Поэтому нам нужно описать 3 раздельных группы ресурсов:
Я думаю, в архитектуру действительно хорошо бы вписалась отдельная функция `current_user `.
Такая стрелочка `~>` помогает легче обновлять библиотеку вручную, непременно с помощью ручного ввода команды на обновление.
А изменения `1.3` не должны убивать приложения на `1.2`, как можно увидеть – изменения вынесены отдельно и являются в некотором роде экспериментальными.
Самая большая проблема FactoryGirl для non-Rails приложений – ActiveSupport в зависимостях.