Насколько я понимаю, если писать с Just так, как обычно пишут на JS, то все чудеса быстродействия сойдут на нет. И, похоже, проект писался специально под бенчмарк (в отличие от большинства прочих представленных там фреймворков).
P.S. Пару недель назад добрался, наконец, до Rust Book и влюбился. Интересно, удастся ли ему набрать достаточно популярности?
Если настроить «натуральные» (2:1) октавы на фортепиано, то биения будут из-за того, что реальные струны несколько отличаются от идеальных, и гармоники у них не вполне совпадают с натуральным звукорядом. Поэтому октавы на фортепиано растягивают при настройке.
Это я к тому, что математические абстракции неизбежно спотыкаются об реальную акустику (в меньшей степени) и психоакустику (в большей степени). И игнорирование реальности приводит к очередным идеальным системам, не имеющим отношение к реальной жизни.
Сколько можно писать про одно и то же! Пифагорейское представление, что красивые числа ведут к красивому звучанию/виду/чему угодно, пару веков как устарело — иначе бы равномерно темперированный строй не стал бы доминировать.
На моем текущем проекте у сущности может быть несколько десятков полей. Ну, пусть даже 10 из них не nullable. Как-то сомнительно их все через конструктор инициализировать.
Вот тут как та ситуация, когда код, который никак не хочет укладыватся в правила статического анализа, имеет некоторые архитектурные проблемы. С точки зрения идеальной архитектуры объект с не-nullable свойствами не может существовать, если у них нет значений. Тут просится что-то промежуточное типа builder'а с валидатором внутри. Но это в идеальном мире, конечно... У нас, кстати, часть таких проблем с пользовательским вводом решена с помощью spatie/data-transfer-object, но это довольно специфичное решение.
Но с точки зрения реального, а не идеального кода всё совсем не так :))) Но осознавать неидеальность, конечно, тоже небесползено.
Я на одном небольшом проекте для себя успешно подружил Psalm с сущностями доктрины. Исходил я примерно из таких принципов:
Если какое-то поле у сущности не может быть null, то оно должно быть проинициализировано в конструкторе. То есть логически, если у нас User не может быть без почты и пароля, тогда конструктор будет их принимать.
Я подумал, что для $id использовал @psalm-suppress PropertyNotSetInConstructor, но заглянул в код и, оказывается, нет. $id честно прописан ?int, и даже это где-то используется для того, чтобы отличать уже записанные в БД сущности от только что сгенерированных. А там, где я точно уверен, что он не null, писал (int)$id.
Вероятно, это можно всё как-то сделать на магии шаблонов, чтобы $em->find() возвращал специально шаблонизированную Entity, у которой $id не может быть null, но быстро набросать у меня не получилось.
Ну и в любом случае, это немного костыльно решается плагином.
Конкретно с Psalm у нас довольно мало false-positives, а огромное количество ошибок прячется в baseline, который со временем постепенно худеет. Ведь при модификации кода практически невозможна ситуация, когда новое выражение точно попадёт в baseline. Это связано с форматом: Psalm фиксирует не только количество ошибок определённого типа в файле, но и конкретное выражение, которое их вызывает.
А вот с JS у нас пока ещё не всё хорошо, ESLint в принципе настроен, но не форсируется. Зато новый код всё больше пишется на Typescript, который сам очень помогает с контролем типов.
В статье много подозрительных мест. Так, написано о свёрточных слоях, а в коде — только Dense. И функция get_state выглядит странно: в массив добавляется только информация о координатах объектов, но не об их типе.
По теневой капче метрика ложноположительных получается из статистики явной капчи: те, которые теневую проверку не прошли, а явную прошли, те, значит, всё-таки белые и пушистые. Кстати, большинство не проходит.
Если Вы не нажмёте на капчу, то от спама Вы всё-таки отличимы, потому что больше запросов от Вас не будет.
Пользователи как раз очень активно пишут, если их что-то не устраивает (кстати, в ссылке уже прописан subject). Жалобы в обратной связи — один из основных способов подстройки параметров так, чтобы реальные пользователи как можно меньше страдали.
Это неверный вывод. Скрипты и прочее отдаются из кеша статики, нагрузку это, конечно, увеличивает, но совсем незначительно. А вот исполнять скрипты по сравнению с парсингом HTML значительно дороже.
Конечно, обходится. Цель — не 100% защита, а усложнение жизни тем, кто хочет нарушать условия.
По каждой конкретной компании не изменяются, да. Но действующих компаний почти четыре миллиона, и постоянно регистрируется ещё, поэтому объём ежедневного обновления достаточно велик.
Переход на подписочную модель не связан с обсуждаемым вопросом, там были другие причины.
Ситуация неправильная, Вы совершенно правы. Открытое государство в идеальном варианте выглядит именно так, как Вы описали.
Но в реальности соответствующие органы не очень-то заинтересованы в открытости, отсюда и разного рода неудобства (а конфликт интересов выглядел бы как один "привилегированный" источник с эксклюзивными доступами).
Такие опасения были, да, но, к счастью, не подтвердились.
Грамотно настроенные параметры (там было несколько итераций донастройки) и теневая капча позволяю сейчас прозрачно пропускать порядка 97% пользователей
Судя по формату скриншота, вы с мобильного телефона, и мобильные операторы, увы, до сих пор выдают нескольким клиентов один и тот же внешний IP. Собственно, теневая капча, возможно, именно поэтому Вас и не пропустила (там сейчас порядка 3% подозрительных запросов с точки зрения гугла, т.е. Вам "повезло" в них попасть).
В данном случае положительный итог в том, что если Вы нажмёте на галочку рекапчи, то довольно долго у Вас не будет никаких проблем с доступом.
Тут, в общем-то, вся ветка и началась с жонглирования терминами. Исходный вопрос сформулирован, как мне кажется, намеренно провокативно, в духе «перестали ли вы пить коньяк по утрам». Мошенники в статье упомянуты лишь один раз в том контексте, что fail2ban от них защищает. Частично.
Что касается «при копировании становится меньше информации», то эта тема столько раз обсуждалась в контексте пиратства, что добавить тут, кажется, нечего.
Насколько я понимаю, если писать с Just так, как обычно пишут на JS, то все чудеса быстродействия сойдут на нет. И, похоже, проект писался специально под бенчмарк (в отличие от большинства прочих представленных там фреймворков).
P.S. Пару недель назад добрался, наконец, до Rust Book и влюбился. Интересно, удастся ли ему набрать достаточно популярности?
Если настроить «натуральные» (2:1) октавы на фортепиано, то биения будут из-за того, что реальные струны несколько отличаются от идеальных, и гармоники у них не вполне совпадают с натуральным звукорядом. Поэтому октавы на фортепиано растягивают при настройке.
Это я к тому, что математические абстракции неизбежно спотыкаются об реальную акустику (в меньшей степени) и психоакустику (в большей степени). И игнорирование реальности приводит к очередным идеальным системам, не имеющим отношение к реальной жизни.
Сколько можно писать про одно и то же! Пифагорейское представление, что красивые числа ведут к красивому звучанию/виду/чему угодно, пару веков как устарело — иначе бы равномерно темперированный строй не стал бы доминировать.
Вот тут как та ситуация, когда код, который никак не хочет укладыватся в правила статического анализа, имеет некоторые архитектурные проблемы. С точки зрения идеальной архитектуры объект с не-nullable свойствами не может существовать, если у них нет значений. Тут просится что-то промежуточное типа builder'а с валидатором внутри. Но это в идеальном мире, конечно... У нас, кстати, часть таких проблем с пользовательским вводом решена с помощью spatie/data-transfer-object, но это довольно специфичное решение.
Но с точки зрения реального, а не идеального кода всё совсем не так :))) Но осознавать неидеальность, конечно, тоже небесползено.
Между прочим, весьма успешная альтернативная стратегия!
У нас level 1, писать новый "чистый" код, в общем-то, все довольно быстро привыкли.
Я на одном небольшом проекте для себя успешно подружил Psalm с сущностями доктрины. Исходил я примерно из таких принципов:
Если какое-то поле у сущности не может быть
null, то оно должно быть проинициализировано в конструкторе. То есть логически, если у насUserне может быть без почты и пароля, тогда конструктор будет их принимать.Я подумал, что для
$idиспользовал@psalm-suppress PropertyNotSetInConstructor, но заглянул в код и, оказывается, нет.$idчестно прописан?int, и даже это где-то используется для того, чтобы отличать уже записанные в БД сущности от только что сгенерированных. А там, где я точно уверен, что он неnull, писал(int)$id.Вероятно, это можно всё как-то сделать на магии шаблонов, чтобы
$em->find()возвращал специально шаблонизированнуюEntity, у которой$idне может бытьnull, но быстро набросать у меня не получилось.Ну и в любом случае, это немного костыльно решается плагином.
Конкретно с Psalm у нас довольно мало false-positives, а огромное количество ошибок прячется в baseline, который со временем постепенно худеет. Ведь при модификации кода практически невозможна ситуация, когда новое выражение точно попадёт в baseline. Это связано с форматом: Psalm фиксирует не только количество ошибок определённого типа в файле, но и конкретное выражение, которое их вызывает.
А вот с JS у нас пока ещё не всё хорошо, ESLint в принципе настроен, но не форсируется. Зато новый код всё больше пишется на Typescript, который сам очень помогает с контролем типов.
В статье много подозрительных мест. Так, написано о свёрточных слоях, а в коде — только
Dense. И функцияget_stateвыглядит странно: в массив добавляется только информация о координатах объектов, но не об их типе.По теневой капче метрика ложноположительных получается из статистики явной капчи: те, которые теневую проверку не прошли, а явную прошли, те, значит, всё-таки белые и пушистые. Кстати, большинство не проходит.
Если Вы не нажмёте на капчу, то от спама Вы всё-таки отличимы, потому что больше запросов от Вас не будет.
Пользователи как раз очень активно пишут, если их что-то не устраивает (кстати, в ссылке уже прописан subject). Жалобы в обратной связи — один из основных способов подстройки параметров так, чтобы реальные пользователи как можно меньше страдали.
Испорченные данные пользователь не видит, они скрываются стилями, показывается только капча.
Описанная в статье система противодействия, по сути, и делает работу парсеров бесполезной, т.е. более дорогой, чем самостоятельная разработка.
API существует в виде закрытой беты, поэтому и не гуглится, и, как писал мой коллега выше, пока что выглядит не слишком востребованным.
Шутки шутками, а, помнится, кто-то из зеркалирующих таки майнил на клиентах.
Это неверный вывод. Скрипты и прочее отдаются из кеша статики, нагрузку это, конечно, увеличивает, но совсем незначительно. А вот исполнять скрипты по сравнению с парсингом HTML значительно дороже.
Конечно, обходится. Цель — не 100% защита, а усложнение жизни тем, кто хочет нарушать условия.
По каждой конкретной компании не изменяются, да. Но действующих компаний почти четыре миллиона, и постоянно регистрируется ещё, поэтому объём ежедневного обновления достаточно велик.
Переход на подписочную модель не связан с обсуждаемым вопросом, там были другие причины.
Ситуация неправильная, Вы совершенно правы. Открытое государство в идеальном варианте выглядит именно так, как Вы описали.
Но в реальности соответствующие органы не очень-то заинтересованы в открытости, отсюда и разного рода неудобства (а конфликт интересов выглядел бы как один "привилегированный" источник с эксклюзивными доступами).
Такие опасения были, да, но, к счастью, не подтвердились.
Грамотно настроенные параметры (там было несколько итераций донастройки) и теневая капча позволяю сейчас прозрачно пропускать порядка 97% пользователей
Прямо сейчас таких нет, но вебархив всё помнит. Вот такое было, например (это ещё старая версия в старом дизайне).
Судя по формату скриншота, вы с мобильного телефона, и мобильные операторы, увы, до сих пор выдают нескольким клиентов один и тот же внешний IP. Собственно, теневая капча, возможно, именно поэтому Вас и не пропустила (там сейчас порядка 3% подозрительных запросов с точки зрения гугла, т.е. Вам "повезло" в них попасть).
В данном случае положительный итог в том, что если Вы нажмёте на галочку рекапчи, то довольно долго у Вас не будет никаких проблем с доступом.
API существует, но на данный момент в статусе закрытой беты, и коммерческую эксплуатацию мы пока что не ведём.
Насколько я понимаю, эта фраза означает то, что ФНС не будет брать денег за доступ к этим наборам, как она, например, берёт за доступ к выгрузкам из ЕГРЮЛ/ЕГРИП или к бухгалтерской отчётности.
Тут, в общем-то, вся ветка и началась с жонглирования терминами. Исходный вопрос сформулирован, как мне кажется, намеренно провокативно, в духе «перестали ли вы пить коньяк по утрам». Мошенники в статье упомянуты лишь один раз в том контексте, что fail2ban от них защищает. Частично.
Что касается «при копировании становится меньше информации», то эта тема столько раз обсуждалась в контексте пиратства, что добавить тут, кажется, нечего.