Насколько я понимаю, если писать с 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 выглядит странно: в массив добавляется только информация о координатах объектов, но не об их типе.
API на данный момент существует в виде закрытой беты, коммерческую эксплуатацию мы пока не ведём.
Контактов ИП, к сожалению, не планируется. Дело в том, что по действующему законодательству они являются персональными данными соответствующих физических лиц и по этой причине не могут быть опубликованы.
Кстати, к вопросу об ответственности: методическими рекомендациями предусмотрено поле "ответственное лицо", его email и даже "телефон ответственного лица" для каждого набора открытых данных. Но на деле в этих полях часто пусто, вот, например, как у прокуратуры в реестре проверок.
Какая жесть. ФССП вообще часто делает странное, у коллеги тоже очень долго не хотели закрывать исполнительное производство, хотя тоже всё было уже давно оплачено.
И на промежуточный вариант тоже было бы интересно посмотреть.
Спасибо! Было бы интересно прочитать более подробное описание, если это возможно
Если я правильно нашёл в тексте, то это «съёмный магнитный диск», то есть подходят дискеты любого размера.
А если серьёзно, то я правильно понял, что запатентован примерно тот же метод, что был описан в посте несколько лет назад?
Насколько я понимаю, если писать с 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выглядит странно: в массив добавляется только информация о координатах объектов, но не об их типе.Надеюсь, что Вы их всё-таки добьёте
ЕГРИП — один из основных источников информации, то, что есть в актуальных выписках, мы показываем.
API на данный момент существует в виде закрытой беты, коммерческую эксплуатацию мы пока не ведём.
Контактов ИП, к сожалению, не планируется. Дело в том, что по действующему законодательству они являются персональными данными соответствующих физических лиц и по этой причине не могут быть опубликованы.
И в результате это помогло?
Кстати, к вопросу об ответственности: методическими рекомендациями предусмотрено поле "ответственное лицо", его email и даже "телефон ответственного лица" для каждого набора открытых данных. Но на деле в этих полях часто пусто, вот, например, как у прокуратуры в реестре проверок.
Какая жесть. ФССП вообще часто делает странное, у коллеги тоже очень долго не хотели закрывать исполнительное производство, хотя тоже всё было уже давно оплачено.
Ого, за нарушение велосипедных правил теперь не только штрафуют, но ещё и до ФССП доходит! Что же там такое случилось?
А как вам это?
https://www.youtube.com/watch?v=B9WPfkXQa_Y
"Так сложилось" и есть мода, разве нет?