Автору статьи огромная просьба хотя бы 1 раз прочитать ее (а статья реально хорошая, интересная), и подправить грамматические ошибки (их очень много, правда, а ведь вроде как «Практически все наши сотрудники получили высшее образование...»).
В любом проекте при переходе с чего-то одного на что-то другое все правится 1 раз, поэтому это странный аргумент. По факту после апдейта на 3.0 даже с 2.8 значительная часть не «hello world» проектов не работает корректно, и да, необходимо, пробежаться везде и по одному разу в каждом моменте подправить. Т.е. нет 100% совместимости. Но, еще раз, естественно, это не переезд на другой фреймворк (включая sf1.4).
По валидаторам:
The PHP7-incompatible constraints (Null, True, False) and their related validators (NullValidator, TrueValidator, FalseValidator) have been removed in favor of their Is-prefixed equivalent.
The class Symfony\Component\Validator\Mapping\Cache\ApcCache has been removed in favor of Symfony\Component\Validator\Mapping\Cache\DoctrineCache.
The constraints Optional and Required were moved to the Symfony\Component\Validator\Constraints\ namespace. You should adapt the path wherever you used them.
The option «methods» of the Callback constraint was removed. You should use the option «callback» instead. If you have multiple callbacks, add multiple callback constraints instead.
The interface ValidatorInterface was replaced by the more powerful interface Validator\ValidatorInterface. The signature of the validate() method is slightly different in that interface and accepts a value, zero or more constraints and validation group. It replaces both validate() and validateValue() in the previous interface.
The interface ValidationVisitorInterface and its implementation ValidationVisitor were removed. The implementation of the visitor pattern was flawed. Fixing that implementation would have drastically slowed down the validator execution, so the visitor was removed completely instead.
Along with the visitor, the method accept() was removed from MetadataInterface.
The interface MetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataContainerInterface was moved to the Mapping namespace and renamed to ClassMetadataInterface.
The interface ClassBasedInterface was removed. You should use Mapping\ClassMetadataInterface instead:
The class ElementMetadata was renamed to GenericMetadata.
The interface ExecutionContextInterface and its implementation ExecutionContext were moved to the Context namespace.
The method addViolationAt() was removed. You should use buildViolation() instead.
The methods validate() and validateValue() were removed. You should use getValidator() together with inContext() instead.
The parameters $invalidValue, $plural and $code were removed from addViolation(). You should use buildViolation() instead. See above for an example.
The method getMetadataFactory() was removed. You can use getValidator() instead and use the methods getMetadataFor() or hasMetadataFor() on the validator instance.
The interface GlobalExecutionContextInterface was removed. Most of the information provided by that interface can be queried from Context\ExecutionContextInterface instead.
The interface MetadataFactoryInterface was moved to the Mapping\Factory namespace along with its implementations BlackholeMetadataFactory and ClassMetadataFactory. These classes were furthermore renamed to BlackHoleMetadataFactory and LazyLoadingMetadataFactory.
The option $deep was removed from the constraint Valid. When traversing arrays, nested arrays are always traversed (same behavior as before). When traversing nested objects, their traversal strategy is used.
The method ValidatorBuilder::setPropertyAccessor() was removed. The validator now functions without a property accessor.
The methods getMessageParameters() and getMessagePluralization() in ConstraintViolation were renamed to getParameters() and getPlural().
The class Symfony\Component\Validator\DefaultTranslator was removed. You should use Symfony\Component\Translation\IdentityTranslator instead.
Это все изменения в именовании классов, их методов и параметров методов в неймспейсе Symfony\Component\Validator. Странно, что вы не столкнулись с тем, что даже те же Optional и Required валидаторов уже нет на прошлом месте.
По поводу FQCN согласен, но цитирую UPGRADE-3.0.md от Symfony:
...the FormFactory::create*() methods is not supported anymore. Pass the fully-qualified class name of the type instead.
Before: $form = $this->createForm(new MyType());
After: $form = $this->createForm(MyType::class);
Поэтому не совсем понятно, где именно вы нашли то, к чему относилось «Нет».
Вот здесь соглашусь полностью.
Просто Symfony 2 не есть именно Symfony 2.8. Т.к. 2.8 — это вообще спец. версия для подготовки к переходу на 3.0. В голосовании же идет речь просто про 2.х, т.е. в том числе 2.0. А 2.0 от 3.0 отличается серьезно, и список изменений очень не маленький.
Мне недавно довелось переводить 2.4 на 3.0 один очень серьезный проект. Так вот, только зачистка на 2.8 заняла 3 дня.
Скорее всего вы просто не используете огромное количество возможностей Symfony.
Вот листинг того, что надо менять при переходе с 2.x на 3.0: https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md.
Но как минимум хотя бы с конструкторами форм вы должны были столкнуться (теперь там не экземпляры FormType, а FormType::class), измененными валидаторами объектов и измененными Yaml конфигами (например, вызов колбеков после конструктора, описание роутов).
Так же есть незначительные, но все же изменения в ContainerBuilder-е, bundle compiler-е, dependecy injection, если вы делаете свои бандлы кастомно прекомпилируемыми.
Понятно, что это не кардинальные изменения по сравнению с 1.x -> 2.x, но если проект серьезный, то несколько дней правок обеспечены.
Вполне вероятно, не спорю. Слышал из его уст на презентации, он мог цитировать.
Естественно, должен быть один язык: понятная и не оспариваемая всеми участникам диалога некая базовая терминология. Если она не заявлена, то есть какая-то предполагаемая для аудитории. Например, на хабре никому не нужно разжевывать акроним IT или сленговый термин «хабр». Входит ли в этот базис математический термин «матрица»… я сомневаюсь. Поэтому чтобы получилось «на пальцах», придется его объяснить. Не только как поле 2х2 с ячейками для хранения данных (отличная вводная), но и откуда, когда вы заполняете 4 ячейки двумя значениями вылезают единицы. И почему ниже нет матриц 3х3, а появляются 3х1. И что вы там с ними вообще дальше творите.
Либо отдельно написать статью «матрицы на пальцах», а в этой предложить всем, кто с ними не знаком, предварительно с ними ознакомиться.
Недавно изучил очень много литературы на английском по Symfony и Doctrine. Что удивительно, в большинстве случаев понятно все с первого прохода. Второй проход нужен выборочно только для практической реализации. С моей точки зрения «на пальцах» — это когда непосвященному слушателю все понятно и интересно по мере изложения. Если не понятно или не интересно, то докладчик плохо подготовился, либо он рассказывает не своей целевой аудитории. Как сказал Стив Джобс, если вы не можете объяснить свою идею 6-илетнему ребенку, это плохая/непонятная/плохо сформулированная идея.
Если читать дальше — да, но вы это не объяснили. Мне как читателю совершенно не понятен этот перескок. Представьте, я вам говорю, что объяснить устройство ДВС очень просто, на пальцах. Смотрите: когда подается ток на свечу, она производит искру. Поэтому в четырех цилиндрах свечи работают со смещением фазы в 90 градусов… откуда фазы? почему в четырех? стоп..!
Вот такие же чувства. Полистав статью дальше, я увижу схему двигателя с 4 цилиндрами, по анимашкам возможно пойму в чем дело, но чтобы реально эффективно понять суть, мне придется снова перечитывать статью полностью с необходимым контекстом. Если не наткнусь еще раз на такую же ловушку. Иначе еще и еще раз. А это скучно, не интересно, не эффективно.
P.S. Статья хорошая, идеи отличные. Критика исключительно из-за того, что вы не реализовали заявленное в аннотации.
Я ничего не понял. Я знаю, что такое метод наименьших квадратов и как его использовать, я знаю, что такое линейные уравнения. Помню, что такое матрицы примерно… но:
Эта прямая должна иметь уравнение типа следующего:
/формула/
Здесь альфа и бета нам неизвестны, но известны две точки этой прямой:
/формула/
Можно записать это уравнение в матричном виде:
… а зачем? Почему вы не объяснили, зачем ее представлять в форме матрицы, если все это решается гораздо быстрее и без них? Откуда взялись единицы в матрице? Поэтому далее читать было уже совершенно не интересно, т.к. в самом начале вы задали слишком высокий уровень, пропустив базовые объяснения. Согласен с одним, все можно разжевать на пальцах, но вы это делать не стали.
ax + b = y
a*1 + b = 1
a*3 + b = 2
Вычитаем из второго первое:
2a = 1, следовательно a = 1/2
b = 1 — a = 1 — 1/2 = 1/2
Функция y = 1/2 * x + 1/2, все, зачем нужна была матрица?
Огромное спасибо, с удовольствием почитаю на праздниках, т.к. тема мне очень интересна. Дома, к сожалению, у меня нет лаборатории и работаю сам с ABS, PLA и био (медицинским) пластиком, но мне всегда было реально интересно — а можно ли как-то заранее предопределить качества пластика, повысив температурные параметры PLA или оставив жесткость ABS придать ей больше прочности. Или оставив 60 градусную температуру биопластика, максимально увеличить его жесткость и прочность после остывания при н.у. У всех этих «ручных» материалов не хватает определенных качеств, из-за чего они годятся в домашних условиях только для прототипирования. В общем, интересно, пишите больше, пишите чаще. Уверен, что данного рода статьи будут интересны не только мне.
С интересом прочитал вступление/введение. А где сама статья? Заинтриговали и… как будто не дописана, просто оборвался текст «на самом интересном месте». Как это делается, в каком виде выдается результат? Есть ли машина, которая по вычисленным параметрам выполняет скрипт создания полимера, создавая нужную влажность, давление и т.д.?
А так получается, что Незнайку Носова прочитал. Просто идеи без конкретных реализаций.
Сейчас зашел в свою аналитику в браузеры за последние 30 дней с надеждой не увидеть динозавров и с грустью подтверждаю их существование:
0.0296% — Internat Explorer 4.0!!! Кто они?!
0.0169% — Internet Explorer 6.0
0.0085% — Internet Explorer 7.0
0.6394% — Internet Explorer 8.0 — вот тут совсем грустно. У меня правило: гарантированно поддерживать все браузеры, где доля посетителей составляет от 0.5%.
А дальше забавнее:
0.0889% — Internet Explorer 9.0
0.2668% — Internet Explorer 10.0
И снова это:
0.7876% — Internet Explorer 11.0
По факту, кол-во пользователей IE11 и IE8 — примерно одинаково. Так что списывать IE8 слишком рано. А судя по тому, что есть еще с IE4, так вообще не получится, пока полностью не пропадет IE как сущность или MS не сделает глобальный принудительный мега-апдейт.
Если железо каким-то чудом сделано так, что рулится только определенной версией браузера!, то такое железо лучше вообще не покупать. Ведь вряд ли это скрывают до покупки. Я из примеров знаю только одну валяющуюся у меня в ящике подаренную IP-камеру, которая только в IE6 работает и нигде больше. И, уверен, можно сделать поддержку и современными браузерами, просто оно того не стоит, т.к. затраты времени и денег на изучение протокола и разработку софта сильно выше, чем стоимость новой.
Так вот, выбирая за основу железо, завязанное на ожидаемо быстро устаревающее ПО, которое компания-разработчик (Microsoft) уже объявила неподдерживаемым и которое даже на момент поддержки не соответствовало стандартам, вы заранее обрекаете себя на ситуацию (это к руководителям), когда дешевле будет разработать все с нуля, чем требовать и обеспечивать поддержку стороннего софта, необходимого для работы вашего ПО.
Тлен.
У меня прекрасно открывается и серфится zakupki.gov.ru и в Chrome, и в Safari, и в Firefox. На Mac Os X IE не поставишь. Или там внутренний интерфейс претензиозный?
По валидаторам:
The PHP7-incompatible constraints (Null, True, False) and their related validators (NullValidator, TrueValidator, FalseValidator) have been removed in favor of their Is-prefixed equivalent.
The class Symfony\Component\Validator\Mapping\Cache\ApcCache has been removed in favor of Symfony\Component\Validator\Mapping\Cache\DoctrineCache.
The constraints Optional and Required were moved to the Symfony\Component\Validator\Constraints\ namespace. You should adapt the path wherever you used them.
The option «methods» of the Callback constraint was removed. You should use the option «callback» instead. If you have multiple callbacks, add multiple callback constraints instead.
The interface ValidatorInterface was replaced by the more powerful interface Validator\ValidatorInterface. The signature of the validate() method is slightly different in that interface and accepts a value, zero or more constraints and validation group. It replaces both validate() and validateValue() in the previous interface.
The interface ValidationVisitorInterface and its implementation ValidationVisitor were removed. The implementation of the visitor pattern was flawed. Fixing that implementation would have drastically slowed down the validator execution, so the visitor was removed completely instead.
Along with the visitor, the method accept() was removed from MetadataInterface.
The interface MetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataInterface was moved to the Mapping namespace.
The interface PropertyMetadataContainerInterface was moved to the Mapping namespace and renamed to ClassMetadataInterface.
The interface ClassBasedInterface was removed. You should use Mapping\ClassMetadataInterface instead:
The class ElementMetadata was renamed to GenericMetadata.
The interface ExecutionContextInterface and its implementation ExecutionContext were moved to the Context namespace.
The method addViolationAt() was removed. You should use buildViolation() instead.
The methods validate() and validateValue() were removed. You should use getValidator() together with inContext() instead.
The parameters $invalidValue, $plural and $code were removed from addViolation(). You should use buildViolation() instead. See above for an example.
The method getMetadataFactory() was removed. You can use getValidator() instead and use the methods getMetadataFor() or hasMetadataFor() on the validator instance.
The interface GlobalExecutionContextInterface was removed. Most of the information provided by that interface can be queried from Context\ExecutionContextInterface instead.
The interface MetadataFactoryInterface was moved to the Mapping\Factory namespace along with its implementations BlackholeMetadataFactory and ClassMetadataFactory. These classes were furthermore renamed to BlackHoleMetadataFactory and LazyLoadingMetadataFactory.
The option $deep was removed from the constraint Valid. When traversing arrays, nested arrays are always traversed (same behavior as before). When traversing nested objects, their traversal strategy is used.
The method ValidatorBuilder::setPropertyAccessor() was removed. The validator now functions without a property accessor.
The methods getMessageParameters() and getMessagePluralization() in ConstraintViolation were renamed to getParameters() and getPlural().
The class Symfony\Component\Validator\DefaultTranslator was removed. You should use Symfony\Component\Translation\IdentityTranslator instead.
Это все изменения в именовании классов, их методов и параметров методов в неймспейсе Symfony\Component\Validator. Странно, что вы не столкнулись с тем, что даже те же Optional и Required валидаторов уже нет на прошлом месте.
...the FormFactory::create*() methods is not supported anymore. Pass the fully-qualified class name of the type instead.
Before: $form = $this->createForm(new MyType());
After: $form = $this->createForm(MyType::class);
Поэтому не совсем понятно, где именно вы нашли то, к чему относилось «Нет».
Просто Symfony 2 не есть именно Symfony 2.8. Т.к. 2.8 — это вообще спец. версия для подготовки к переходу на 3.0. В голосовании же идет речь просто про 2.х, т.е. в том числе 2.0. А 2.0 от 3.0 отличается серьезно, и список изменений очень не маленький.
Мне недавно довелось переводить 2.4 на 3.0 один очень серьезный проект. Так вот, только зачистка на 2.8 заняла 3 дня.
Вот листинг того, что надо менять при переходе с 2.x на 3.0: https://github.com/symfony/symfony/blob/master/UPGRADE-3.0.md.
Но как минимум хотя бы с конструкторами форм вы должны были столкнуться (теперь там не экземпляры FormType, а FormType::class), измененными валидаторами объектов и измененными Yaml конфигами (например, вызов колбеков после конструктора, описание роутов).
Так же есть незначительные, но все же изменения в ContainerBuilder-е, bundle compiler-е, dependecy injection, если вы делаете свои бандлы кастомно прекомпилируемыми.
Понятно, что это не кардинальные изменения по сравнению с 1.x -> 2.x, но если проект серьезный, то несколько дней правок обеспечены.
Естественно, должен быть один язык: понятная и не оспариваемая всеми участникам диалога некая базовая терминология. Если она не заявлена, то есть какая-то предполагаемая для аудитории. Например, на хабре никому не нужно разжевывать акроним IT или сленговый термин «хабр». Входит ли в этот базис математический термин «матрица»… я сомневаюсь. Поэтому чтобы получилось «на пальцах», придется его объяснить. Не только как поле 2х2 с ячейками для хранения данных (отличная вводная), но и откуда, когда вы заполняете 4 ячейки двумя значениями вылезают единицы. И почему ниже нет матриц 3х3, а появляются 3х1. И что вы там с ними вообще дальше творите.
Либо отдельно написать статью «матрицы на пальцах», а в этой предложить всем, кто с ними не знаком, предварительно с ними ознакомиться.
Вот такие же чувства. Полистав статью дальше, я увижу схему двигателя с 4 цилиндрами, по анимашкам возможно пойму в чем дело, но чтобы реально эффективно понять суть, мне придется снова перечитывать статью полностью с необходимым контекстом. Если не наткнусь еще раз на такую же ловушку. Иначе еще и еще раз. А это скучно, не интересно, не эффективно.
P.S. Статья хорошая, идеи отличные. Критика исключительно из-за того, что вы не реализовали заявленное в аннотации.
Эта прямая должна иметь уравнение типа следующего:
/формула/
Здесь альфа и бета нам неизвестны, но известны две точки этой прямой:
/формула/
Можно записать это уравнение в матричном виде:
… а зачем? Почему вы не объяснили, зачем ее представлять в форме матрицы, если все это решается гораздо быстрее и без них? Откуда взялись единицы в матрице? Поэтому далее читать было уже совершенно не интересно, т.к. в самом начале вы задали слишком высокий уровень, пропустив базовые объяснения. Согласен с одним, все можно разжевать на пальцах, но вы это делать не стали.
ax + b = y
a*1 + b = 1
a*3 + b = 2
Вычитаем из второго первое:
2a = 1, следовательно a = 1/2
b = 1 — a = 1 — 1/2 = 1/2
Функция y = 1/2 * x + 1/2, все, зачем нужна была матрица?
А так получается, что Незнайку Носова прочитал. Просто идеи без конкретных реализаций.
0.0296% — Internat Explorer 4.0!!! Кто они?!
0.0169% — Internet Explorer 6.0
0.0085% — Internet Explorer 7.0
0.6394% — Internet Explorer 8.0 — вот тут совсем грустно. У меня правило: гарантированно поддерживать все браузеры, где доля посетителей составляет от 0.5%.
А дальше забавнее:
0.0889% — Internet Explorer 9.0
0.2668% — Internet Explorer 10.0
И снова это:
0.7876% — Internet Explorer 11.0
По факту, кол-во пользователей IE11 и IE8 — примерно одинаково. Так что списывать IE8 слишком рано. А судя по тому, что есть еще с IE4, так вообще не получится, пока полностью не пропадет IE как сущность или MS не сделает глобальный принудительный мега-апдейт.
Пойду выпью кофе, не ожидал =(
Так вот, выбирая за основу железо, завязанное на ожидаемо быстро устаревающее ПО, которое компания-разработчик (Microsoft) уже объявила неподдерживаемым и которое даже на момент поддержки не соответствовало стандартам, вы заранее обрекаете себя на ситуацию (это к руководителям), когда дешевле будет разработать все с нуля, чем требовать и обеспечивать поддержку стороннего софта, необходимого для работы вашего ПО.
Тлен.