Показатели js, python и bash противоречат этому. Непонятно только, под магией что имеется в виду. Если магия рельс, то это не должно относится к языку. А так, огонь и затмения тоже когда-то считались магией.
Sass, yaml, haml и coffee вдохновлены python'ом. В спецификации yaml так и сказано: YAML's indentation based block scoping is similar to Python's .... А то, что они реализованы впервые были на руби, говорит о другом.
Например, "все есть объект" без исключений, в отличии от других ОО-языков. Модель наследования очень гибкая (самая гибкая?). Развитые возможности метапрограммирования. Но это все не оценят люди, знакомые с языком поверхностно.
Мог бы предположить, что дизлайкают за отсутствие статической типизации и проверки типов, но по результатам всем нравятся JS и Python. И bash :) Сейчас только обратил внимание.
Вообще, в предыдущих исследованиях SO вроде показали, что большая часть (с отрывом) аудитории — разработчики JS и SQL :) Так что столько дизлайков в сторону бэкенд языков, ничего могут и не значить кроме того, что они просто кому-то не нравятся в интернете.
Скажите, пожалуйста, есть ли практическая разница для приложений в том, чтобы иметь отдельное значение doc_tsv вместо построения индекса gin(to_tsvector(doc)) и в запросах использовать to_tsvector(doc) @@ to_tsquery('...'). Такой индекс ведь используется при запросе, и не расходуется дополнительное место под doc_tsv?
У меня такая проблем была, из-за того что я изменял дефолтную тему через PackageResourceViewer. Я удалил измененную, скопировав правки в копию новой. В окнах я не знаю, где лежат эти файлы, для пользователей макоса: ~/Library/Application Support/Sublime Text 3/Packages.
А пользователю тоже показывать ERROR: null value in column "username" violates not-null constraint? Изначально обсуждались валидации, результат которых виден пользователю. Целостность данных — совсем другое, trailblazer к ней мало отношения имеет (вообще не имеет?).
А если в операции обновления не будет найдена редактируемая запись?
404 нам всегда было достаточно.
Вполне возможно, что у меня все задачи проще были, и я не могу оценить пользу reform. В любом случае, на примерах реальных приложений было бы продуктивнее обсуждать, чем на абстрактных задачах.
failure вызывает метод обработчик, если один из предыдущих step вернул false
Неявный возврат в руби не располагает к такому решению. Видимо, ещё предстоит переход на throw :abort.
В итоге, я пришёл к такому флоу ...
Ситуация "форма разрешила сохранять, а модель нет, и 500 из-за этого", не всем бы подошла. Получается в форме просто забыли добавить валидацию, которая появилась в модели. Архитектура должна защищать от таких ошибок. Думаю, общие валидации в AR/главных моделях не надо избегать. А вот админские/юзерские выносить в операции/форм-объекты/другое-название — это хорошо.
Именно от этого Trailblazer призывает уйти
Не проблема — последние 2 варианта. Еще можно объединить валидации из модели и формы так:
include ActiveModel::Validations
delegate :errors, to: :model
validates :checkbox, presence: true
validate { errors.add :name if smth? }
def valid?
model.valid? && super
end
Да, я именно про ActiveModel как form object писал.
Пример я взял с http://trailblazer.to/gems/operation/2.0/. Сам я трэйлблэйзер не использовал и не знаю, что именно делает failure. Предположил, что он ловит ошибки. Ошибки валидации можно сделать доступными разными способами (все под задачу и/или по договоренностям в команде):
operation.model.errors
# или
delegate :errors, to: :model
# или
include ActiveModel::Validations
# или
def ...
@errors = ActiveModel::Errors.new(self)
end
call вполне может быть изменен, чтобы возвращать false в случае ошибки вместо рерэйза.
Показатели js, python и bash противоречат этому. Непонятно только, под магией что имеется в виду. Если магия рельс, то это не должно относится к языку. А так, огонь и затмения тоже когда-то считались магией.
Такими я представляю себе значимую часть их developer stories :)
Sass, yaml, haml и coffee вдохновлены python'ом. В спецификации yaml так и сказано:
YAML's indentation based block scoping is similar to Python's .... А то, что они реализованы впервые были на руби, говорит о другом.Правильные бэкенд разработчики будут рады выбросить humanize, i18n и что-бы фронтендеры сами с локализацией развлекались.
Про sass-scss тоже обобщение. Во всех проектах, где учавствовал, только scss использовали, про sass даже не обсуждали.
Про кэмлкейс — к языку не относится, в любом языке могут начаться холивары по стайлгайду. Кто-то бывает и на руби в кэмлкейсе пишет.
Например, "все есть объект" без исключений, в отличии от других ОО-языков. Модель наследования очень гибкая (самая гибкая?). Развитые возможности метапрограммирования. Но это все не оценят люди, знакомые с языком поверхностно.
Мог бы предположить, что дизлайкают за отсутствие статической типизации и проверки типов, но по результатам всем нравятся JS и Python. И bash :) Сейчас только обратил внимание.
Вообще, в предыдущих исследованиях SO вроде показали, что большая часть (с отрывом) аудитории — разработчики JS и SQL :) Так что столько дизлайков в сторону бэкенд языков, ничего могут и не значить кроме того, что они просто кому-то не нравятся в интернете.
Может быть разработчики PHP и Ruby дизлайкают друг-друга?)
Почитать бы эти developer stories, но они, видимо, видны только автору или работодателям.
Спасибо за подробное объяснение! :)
Я индекс немного по-другому строил, по-этому не столкнулся с
must be marked IMMUTABLE:У такого подхода нет минусов кроме того, что поиск только для заранее заданного языка будет использовать индекс?
Спасибо за ваши статьи!
Скажите, пожалуйста, есть ли практическая разница для приложений в том, чтобы иметь отдельное значение
doc_tsvвместо построения индексаgin(to_tsvector(doc))и в запросах использоватьto_tsvector(doc) @@ to_tsquery('...'). Такой индекс ведь используется при запросе, и не расходуется дополнительное место подdoc_tsv?Похоже, тут объяснение: http://vessenes.com/more-ethereum-attacks-race-to-empty-is-the-real-deal/
Security through obscurity :)
Если шаги именно сделаны, то это только 1 вариант — назад-вперед-вперед. Вероятность 2/3 х 1/3 х 1/3 = 2/27.
Мне спам уже давно не приходит, только "официальный".
Как он тогда, просто узнавая синтаксис, говорит "Почему Elixir не Ruby, а лучше"?
Дальше больше: "Просто не люблю Go и все."
У меня такая проблем была, из-за того что я изменял дефолтную тему через PackageResourceViewer. Я удалил измененную, скопировав правки в копию новой. В окнах я не знаю, где лежат эти файлы, для пользователей макоса:
~/Library/Application Support/Sublime Text 3/Packages.А пользователю тоже показывать
ERROR: null value in column "username" violates not-null constraint? Изначально обсуждались валидации, результат которых виден пользователю. Целостность данных — совсем другое, trailblazer к ней мало отношения имеет (вообще не имеет?).404 нам всегда было достаточно.
Вполне возможно, что у меня все задачи проще были, и я не могу оценить пользу reform. В любом случае, на примерах реальных приложений было бы продуктивнее обсуждать, чем на абстрактных задачах.
Неявный возврат в руби не располагает к такому решению. Видимо, ещё предстоит переход на
throw :abort.Ситуация "форма разрешила сохранять, а модель нет, и 500 из-за этого", не всем бы подошла. Получается в форме просто забыли добавить валидацию, которая появилась в модели. Архитектура должна защищать от таких ошибок. Думаю, общие валидации в AR/главных моделях не надо избегать. А вот админские/юзерские выносить в операции/форм-объекты/другое-название — это хорошо.
Не проблема — последние 2 варианта. Еще можно объединить валидации из модели и формы так:
Да, я именно про ActiveModel как form object писал.
Пример я взял с http://trailblazer.to/gems/operation/2.0/. Сам я трэйлблэйзер не использовал и не знаю, что именно делает failure. Предположил, что он ловит ошибки. Ошибки валидации можно сделать доступными разными способами (все под задачу и/или по договоренностям в команде):
callвполне может быть изменен, чтобы возвращать false в случае ошибки вместо рерэйза.Нет. Думал, что не вижу.
Интересная новая услуга у хабра.