LIVR — «независимые от языка правила валидации» или валидация данных без «проблем»

Да, нужно будет портировать правило на другой язык. На деле редко бывает нужно, да и правила это не огромные простыни кода, портирование которых может вызвать проблемы. Но сама схема при этом останется прежней. В этом и есть независимость. В JsonSchema это достигается по сути изобретением своего языка для описания правил, который во первых очень ограничен, во вторых его еще как-никак нужно учить.

LIVR — «независимые от языка правила валидации» или валидация данных без «проблем»

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

LIVR это больше чем просто набор стандартных правил, одна из основных идей в том чтоб можно было легко добавлять свои. В стандартной поставке идут только те, которые будут нужны почти всем.

Например, в json-schema для чисел есть проверка на делимость (multipleOf)
Ещё в схеме есть patternProperties, позволяющий проверять имя ключа по регулярке, это порой бывает нужно

Вот примеры правил которые редко бывает нужны. Их можно легко описать самому. При этом правило пишется на обычном языке программирования, и соответственно можно реализовать что угодно (например валидацию, которая зависит от значения получаемого из БД) в отличии от.

для строк — regexp

см. правило like.

Можно также вынести все свои типы в какой-то отдельный файл, а и через $ref их использовать

Регистрируете свои правила, потом их используете.

В целом, для простых схем LIVR хорош, но сложные — пока что не его конёк.

Ну и далее в том же духе. Вы просто не поняли основную идею, возможно стоит еще раз прочитать статью?

LIVR — «независимые от языка правила валидации» или валидация данных без «проблем»

Автор написал:
> Сложный формат для правил. Хочется, чтобы структура с правилами была максимально близка к структуре с данными. Попробуйте описать этот пример на JSON Schema

Он не ставил под сомнение возможность описать это в JSON Schema, он говорил что получится структура слабо похожая на структуру данных. Что собственно, и было вами доказано. Да и вообще простыня знатная получилась, раза в три длинней чем

{
    order_id: ['required', 'positive_integer'],
    product_ids: [{
       'list_of': [ 'required',  'positive_integer' ]
    }]
}

LIVR — «независимые от языка правила валидации» или валидация данных без «проблем»

См. правило «like»

LIVR — «независимые от языка правила валидации» или валидация данных без «проблем»

Выглядит так, как будто вы не читали статью.

Как я стал мейнтейнером одного из модулей Perl на CPAN

Не так давно была проблема с Lingua::RU::Number, написал автору, он был очень удивлен, но все порешал.
На проблему с использованием последней версии Moose в модуле Net::Amazon::S3 долго никто не реагировал, форкнул себе на гитхаб и ставил оттуда через dev версию Carton'a пока ее все таки не решили.

Не мамонт ли Вы? (пятничный тест; который ложь, да в ней намек)

> PHPStorm?
Спор насчет редакторов и\или ide переживет еще не одного грозного питекантропа.
И да, только ископаемые моллюски пишут исключительно на одном на php (или любом другом языке). Тем более используя php-специфичную ide. Почему использовать несколько разных ide плохо, объяснять я надеюсь не нужно.

5 функций объекта Console, о которых Вы не знали

А вообще — спасибо, нужно это помнить, из за этого не работает код вида

somePromise
    .catch(console.error)
    .then(console.log)
    .done();

Грабли mongoose

Я расскажите пожалуйста, зачем нужно отключать его в production? Я бегло прогуглил, тут тоже не понимают.

5 функций объекта Console, о которых Вы не знали

Ок, факт.

5 функций объекта Console, о которых Вы не знали

А вот и не факт. Если я положу пару функций в хэш или массив, это еще не делает их методами.
</зануда>

Взаимодействие с командной строкой perl 6 из функции MAIN

Весьма неплохо, для простых скриптов должно быть очень удобно. Для остального — есть docopt.

Разрабатываем систему аналитики

ОМГ, как же это достало! Почему вам так надо написать такой первый коммент к статье которая содержит любой, абсолютно любой код на перле? Код в статье плохо написан? Не читабелен? Не работает? Думаю ты его даже не пытался прочесть.

Yeoman для новичков

Ценность всего этого дела видимо только в генераторах шаблонов. Если же сам шаблон проекта мне не подходит — выходит нужно писать свой генератор. Да только зачем мне писать генератор если шаблон у меня уже есть? Разве что для того чтоб с другими им поделится. Мне кажется достаточно было бы создать каталог шаблонов проектов с описаниями в одном формате. Это реализовать проще, и авторам легче добавлять в каталог свои шаблоны (не нужно разбираться с тем как генератор написать), и нагляднее для разработчиков (сразу видно не генератор, а итоговый результат).

Вышел Skype 4.3 для Linux

Поставил версию из репозитория для 14.04 на 13.10, все супер. Спасибо!

Удалено

Все равно не плохо, особенно если не тратить на это 2 года.

ZenComment и преодоление «бешеной плитки» на Хабре

Никогда не понимал этих волн негодования по поводу нового интерфейса. Напоминает «Дуров, верни стену» =)

Никто не умеет обрабатывать ошибки

Два вопроса:
— Какое это отношение имеет к статье?
— Нафига постить текст как картинку?

J может быть читаемым

Да, Perl и правда курит в сторонке, он позволяет писать какой угодно код, хоть запутанный, хоть самодокументированный, в отличии от. Тем не менне, с автором статьи согласен, эти правила никому не мешали.

Node.js vs Ruby on Rails

> Product.find(params[:id])
> доступный повсюду из приложения, модулей, контроллеров и вью в Rails.

Но это же хрестоматийный буллшит!