Изначально я планировал, что создавать валидаторы можно только для базовых простых скалярных типов.
Теоретически, можно было бы сделать так:
Username(anotherConstraint)
Но не уверен, как сейчас отреагируют на такое библиотеки, и это не описано в RFC.
Надо подумать, стоит ли давать возможность навешивать констрейнты на типы, производные от базовых. Здесь вопрос в том, не усложнит ли это интерпретацию кода пользователем
Констрейнты в квадратных скобках - специфичные для массивов ограничения
Email(domain:'gmail.com')[min:1]
Здесь описан массив, состоящий из элементов типа Email(domain:'gmail.com'), в котором должен быть минимум один элемент. Можно написать чуть по-другому, так будет нагляднее
type GmailEmail = Email(domain:'gmail.com')
type User = {
emailsList: GmailEmail[min:1]
}
Невстроенные валидаторы нужны для доменно-специфичных вещей и переиспользования. Валидаторы сами по себе могут быть не очень читаемыми, и совмещение типа и валидатора вместе может вызывать сильную когнитивную нагрузку при чтении.
Несколько валидаторов в один сами по себе не собираются. Валидатор присоединяется к типу как констрейнт. Можно сказать, что пользовательский тип - это базовый тип + констрейнты. На тип можно навесить несколько констрейнтов:
validator String(alphaOnly) = this matches /[a-zA-z]+/
type Username = String(alphaOnly, min:3, max:10)
Здесь я навесил на тип три констрейнта (один пользовательский и два встроенных), и, для удобства использования, дал этому сложному типу алиас
Если говорить именно о моей задаче описания ТЗ, то да, OpenApi вполне подходил. В том случае я не стал его использовать из-за моего личного к нему отношения. Я не считаю его читабельным.
Если говорить в общем о сравнении OpenApi и Scedel, то:
OpenApi протоколо-центричный. Это прекрасно для описания REST-апи, однако ограничивает его использование;
OpenApi использует YAML, что с одной стороны хорошо, так как YAML - это устоявшийся формат, с которым умеют работать все системы. С другой стороны, из-за подчинения синтаксису YAML, OpenApi становится очень объемным в описании сложных схем (такая же проблема, как и в JSON Schema)
Мне показалось, что вы очень пренебрежительно относитесь к колегам
мало кто знает что в практических задачах она никогда не является целью
Так уж прям мало кто?
К сожалению, мало кто из русскоязычной аудитории сможет разделить мой восторг по поводу такой возможности, потому что это уже практически забытая технология
Динамические библиотеки - это не забытая технология. А еще, как близкая, концепция - микросервисы.
Ну и вообще, подмена реализаций - это обычная штука, логично вытекающая из механизма интерфейсов. Инъекция зависимостей - это вообще один из базовых архитектурных паттернов.
В общем, лайкнул бы статью, если бы она позиционировалась как статья для новичков, так как объясняет базовые, но полезные вещи
Я решал проблему созданием SearchCriteria, которая сама добавляет условия в QueryBuilder.
Но на самом деле проблема разрастания репозитория решается довольно просто: достаточно в репозитории держать только common-функции, а специфичные для бизнес-логики реализовывать в сервисном слое. Никогда не понимал подхода, когда на любой чих добавляют функцию в репозиторий
Странно, я много раз про это слышал, причем и из источников, которым я доверяю, что для меня это стало само собой разумеющимся, так что даже не задумывался над пруфами.
Конечно, без полного контекста трудно что-то сказать.
Но я зацепился за слово "требую". Я очень редко что-то требую от своих ребят. Когда у нас появляется какая-то систематическая проблема, мы вместе ищем её решение.
Проблема с код ревью вообще частая, и у нас она тоже периодически возрождается
В Китае он заблокирован, и этот факт не делает китайцев несчастными.
Китайцев полтора миллиарда, они внутри своих РАЗВИТЫХ платформ могут генерировать в 10 раз больше контента, чем россияне
Ещë я понял, что либерализмом в России называют, по сути, экстремистское объединение, навязывающее буллинг и культуру отмены, если твой публичное мнение отличается от мнения агрессивного меньшинства.
Ну, навязывание буллинга и культуры отмены не страшнее, чем навешивание ярлыков "иноагент" и "предатель родины"
Вам, всего-лишь, блокируют доступ к ресурсу с развлекательными видосикам
Не только развлекательными
При том, не капитально блокируют
Невозможность посмотреть без обхода блокировки - это не капитально?
Как раз-таки спринты дают результат реже, и добиться качественного планирования спринта очень сложно. Все потому, что спринты работают с будущим, а вип-лимиты с настоящим. Но вообще, вип-лимиты и спринты - это не взаимоисключающие техники, их можно использовать совместно.
Не важно, что задачи могут сильно варьироваться в пределах одного этапа. Главное, что мы ограничиваем количество именно одновременной работы. Над чем большим количеством одновременных задач работает человек, тем хуже. При этом не так важно, сколько задач сделал работник за единицу времени. Один может подряд настругать десяток задач за неделю, а второй будет заниматься только одной. Главное, что оба этих человека не переполнены параллельными задачами
Вот за Internet Suite вам спасибо! Я давно говорю, что тот же Хром - это не браузер, а просто просматривалка сайтов. У меня почти вся жизнь и работа проходят в интернете, и функционала Хрома, даже обвешанного расширениями, мне не хватает. Хром - это как писать код в блокноте, вместо того, чтобы использовать IDE
Спасибо!
Отмечу, что JSON Schema и Scedel не совсем конкуренты.
JSON Schema - это, в первую очередь, язык описания правил валидации.
Scedel - это язык для моделирования типов и контрактов, а валидация - это побочное свойство.
Это хороший вопрос, спасибо!
Изначально я планировал, что создавать валидаторы можно только для базовых простых скалярных типов.
Теоретически, можно было бы сделать так:
Но не уверен, как сейчас отреагируют на такое библиотеки, и это не описано в RFC.
Надо подумать, стоит ли давать возможность навешивать констрейнты на типы, производные от базовых. Здесь вопрос в том, не усложнит ли это интерпретацию кода пользователем
Констрейнты в квадратных скобках - специфичные для массивов ограничения
Здесь описан массив, состоящий из элементов типа
Email(domain:'gmail.com'), в котором должен быть минимум один элемент. Можно написать чуть по-другому, так будет нагляднееНевстроенные валидаторы нужны для доменно-специфичных вещей и переиспользования. Валидаторы сами по себе могут быть не очень читаемыми, и совмещение типа и валидатора вместе может вызывать сильную когнитивную нагрузку при чтении.
Несколько валидаторов в один сами по себе не собираются. Валидатор присоединяется к типу как констрейнт. Можно сказать, что пользовательский тип - это базовый тип + констрейнты. На тип можно навесить несколько констрейнтов:
Здесь я навесил на тип три констрейнта (один пользовательский и два встроенных), и, для удобства использования, дал этому сложному типу алиас
Если говорить именно о моей задаче описания ТЗ, то да, OpenApi вполне подходил. В том случае я не стал его использовать из-за моего личного к нему отношения. Я не считаю его читабельным.
Если говорить в общем о сравнении OpenApi и Scedel, то:
OpenApi протоколо-центричный. Это прекрасно для описания REST-апи, однако ограничивает его использование;
OpenApi использует YAML, что с одной стороны хорошо, так как YAML - это устоявшийся формат, с которым умеют работать все системы. С другой стороны, из-за подчинения синтаксису YAML, OpenApi становится очень объемным в описании сложных схем (такая же проблема, как и в JSON Schema)
Мне показалось, что вы очень пренебрежительно относитесь к колегам
Так уж прям мало кто?
Динамические библиотеки - это не забытая технология. А еще, как близкая, концепция - микросервисы.
Ну и вообще, подмена реализаций - это обычная штука, логично вытекающая из механизма интерфейсов. Инъекция зависимостей - это вообще один из базовых архитектурных паттернов.
В общем, лайкнул бы статью, если бы она позиционировалась как статья для новичков, так как объясняет базовые, но полезные вещи
Тут была ошибка руководства, что неопытного сотрудника оставили без контроля. По-хорошему, у ТС должен был быть наставник
Я решал проблему созданием SearchCriteria, которая сама добавляет условия в QueryBuilder.
Но на самом деле проблема разрастания репозитория решается довольно просто: достаточно в репозитории держать только common-функции, а специфичные для бизнес-логики реализовывать в сервисном слое. Никогда не понимал подхода, когда на любой чих добавляют функцию в репозиторий
Это забавный эксперимент, однако думаю, что лучше смотреть на размеры бинарника, а не исходного кода
Отписался комментарием выше.
Про Казимира - это же по факту та же отрицательная энергия, ну или по крайней мере ложноотрицательная
Странно, я много раз про это слышал, причем и из источников, которым я доверяю, что для меня это стало само собой разумеющимся, так что даже не задумывался над пруфами.
Сейчас поискал - есть две работы:
https://arxiv.org/pdf/2102.06824 - здесь про субсветовой варп
https://arxiv.org/pdf/2006.07125 - здесь про сверхсветовой
Ну так пузырь Алькубьерре уже даже отрицательной энергии не требует
Конечно, без полного контекста трудно что-то сказать.
Но я зацепился за слово "требую". Я очень редко что-то требую от своих ребят. Когда у нас появляется какая-то систематическая проблема, мы вместе ищем её решение.
Проблема с код ревью вообще частая, и у нас она тоже периодически возрождается
Китайцев полтора миллиарда, они внутри своих РАЗВИТЫХ платформ могут генерировать в 10 раз больше контента, чем россияне
Ну, навязывание буллинга и культуры отмены не страшнее, чем навешивание ярлыков "иноагент" и "предатель родины"
Не только развлекательными
Невозможность посмотреть без обхода блокировки - это не капитально?
Прошу прощения, плохо знаком с питоном. Но чем это отличается от DataMapper и использования репозиториев?
Как раз-таки спринты дают результат реже, и добиться качественного планирования спринта очень сложно. Все потому, что спринты работают с будущим, а вип-лимиты с настоящим. Но вообще, вип-лимиты и спринты - это не взаимоисключающие техники, их можно использовать совместно.
Не важно, что задачи могут сильно варьироваться в пределах одного этапа. Главное, что мы ограничиваем количество именно одновременной работы. Над чем большим количеством одновременных задач работает человек, тем хуже. При этом не так важно, сколько задач сделал работник за единицу времени. Один может подряд настругать десяток задач за неделю, а второй будет заниматься только одной. Главное, что оба этих человека не переполнены параллельными задачами
Есть огромное количество классных игр с бюджетом в банку пива. Сроки и бюджет никак не коррелируют с качеством, только с масштабом
Можно еще вместо fgets() использовать stream_get_line(). По моим тестам даёт еще примерно 25% производительности на однопотоке
Я хочу сказать. Но так как оскорбления запрещены, то просто напишу: вот свою информацию и раздавайте как вам хочется. А мою не трогайте
Вот за Internet Suite вам спасибо! Я давно говорю, что тот же Хром - это не браузер, а просто просматривалка сайтов. У меня почти вся жизнь и работа проходят в интернете, и функционала Хрома, даже обвешанного расширениями, мне не хватает. Хром - это как писать код в блокноте, вместо того, чтобы использовать IDE