Что есть что
Для начала давайте расскажу мой опыт разработки и ощущения от инструментов на других языках, чтобы вы поняли с чем я сравниваю.
Python. Когда речь заходит о проектах на python (чаще всего на Django), мы получаем платформу, которая позволяет достаточно удобно и просто наращивать функционал, строить rest-api сервера, проводить шардирование системы и прочее. Логика работы фреймворка очень понятная и прямолинейная. Даже совсем зеленый разработчик может за пару часов набросать небольшой бложик с админкой. Плюс документация Django – одна из самых качественных, что я видел. К этому всему добавляется синтаксический сахар python, который помогает реализовывать определенные паттерны весьма элегантно. Если мы отходим от Django в сторону Tornado/aiohtpp/Twisted/Flask итд – то там начинается боль, ибо код в них писать гораздо неприятней, чем в Django.
Java. Если мы говорим про Java, например, Spring – то это системы, которые вызывают анальную боль тем, что заставляют тебя конфигурировать все, что можно конфигурировать. Порог вхождения очень высокий, огромное число нюансов, которое нужно держать в голове, плюс сам синтаксис Java заставляет тебя писать весьма объемные конструкции (правдиво для всех проектах на шестой Java). Но в качестве награды мы получаем весьма надежные и гибкие системы, которые могут пережить не один десяток программистов с весьма посредственными руками.
Что же касается PHP
Перед началом работы я прочитал книгу: Мэтт Зандра – PHP объекты, шаблоны и методики программирования, и убедился, что PHP в общем-то без особой боли позволяет реализовывать те или иные паттерны разработки. Т.е. в PHP можно писать правильный код, который будет не сильно отличаться от того, что мы получаем на Python/Java.
Zend Framework 1
Проект внутреннего сервиса меня встретил Zend Framework 1 на PHP 5.3. Скажу сразу, что многие решения на данной платформе выглядят весьма спорно, а язык PHP 5.3 имеет ограничения на установление типа возврата функций (методов), тем не менее, достаточно быстро понимаешь, где что лежит, как что прокидывается, а как что формируется.
Например, если мы рассматривает Zend Forms, то они практически под копирку делают то, что делают классические формы в Django. Синтаксис построения запросов в ДБ Zend DB Table – не вызывает какого-то негатива, и весьма очевидно работает.
Т.е. буквально за 2-3 дня я смог полноценно разбираться и стал писать код, который делал то, что от него требовалось вполне адекватным способом.
Symfony 3.4
Спустя 3 месяца меня перевели на другой проект на Symfony 3.4 и PHP 7.1 – и вот это просто бомба. У меня откровенно было ощущение, что мне дали в ручки Django, куда добавили надежность системы из Java.
- Шаблонизатор Twig – полный клон Jinja от Django.
- Doctrine ORM – аналог Hibernate
- Аннотации Symfony – аналог декораторов из Python
- Auto-wiring Symfony – даже работает очевидней, чем DI в Spring
- Очевидные конфигурации секрьрности
- Удобное построение rest-APi клиентов.
- Удобное написание джоб для крона (в данном случае в симфонии они называются консольные команды)
- Удобный дебагер и консольный помощник.
Плюс сам язык PHP 7.1 уже позволял указывать возвращаемые типы, делать мульти перехватчик исключений и прочие ништяки. И скажем так, пропал абсолютно какой-либо дискомфорт от работы с инструментом. И в некоторых местах все работает даже удобней.
Единственный жирный минус – это недостаточная документация. Т.е. в документации указываются самые простые кейсы, а все что интересней, уже требует копания в исходниках symfony, ну и фреймворк на удивление не так популярен в Гугле, как бы того хотелось.
Поэтому, я абсолютно не понимания, почему люди плюют в сторону PHP, когда он работает и весьма клево.
А есть ли разница
Также хочу отметить такой момент, что после того, как ты поработал на 3-4 современных веб-фреймворках, тебе приходит понимание, что все везде работает схожим образом. Отличаются названия и реализации, а общие концепции 1 в 1. Поэтому, скажем, если вы работали на Django, то пересесть на php Symfony / .Net CORE MVC – можно без особо труда за пару месяцев.
P.S.: если я все же слеп и глуп, прошу в комментарии.
Комментарии (353)
VolCh
26.03.2019 14:53+3Как мне кажется, больше всего хейтят PHP те, кто ушёл с него где-то на 4 версии, максимум с 5.2. Или те, кто в основном работал в єкосистеме WordPress и Joomla. Собственно оба варианта почти одно и то же, пускай и во втором формально последний PHP сейчас поддерживается.
P.S. А аналог Doctrine (DataMapper ORM) появился? Или всё разновидности ActiveRecord?
Warrangie
26.03.2019 19:08+3Вы так мастерски объяснили почему хейтят php и так лицемерно сделали то же самое с двумя популярными cms.
Php хейтят по инерции, причем в основном те, кто его не использует и те, кто его использует, но не знает толком. На хабре периодически появляются статьи вида "ухожу из пхп потому что он не очень" от ребят, которые толком не знают о чем пишут.
А про джумлу — будьте добры, изучите хоть немного то, о чем говорите. А то получается что вы осуждаете людей за собственные ошибки и не видите этого. Есть масса отличных разработчиков, которые пишут под джумлу и масса хреновых, которые используют {подставить имя} фреймворк, а вы сейчас всех под одну гребёнку, неприятно, знаете ли. Почему вы считаете что если человек пишет не под ту систему, во вам нравится, то он априори не очень?
HEKET313
26.03.2019 20:20А где в комментарии выше высказывание, что те, кто пишут под джумлу и wp не очень? Там конкретно про эти фреймворки написано. Я не работал под Joomla, а проекты на wp обходил стороной, весьма не приятные воспоминания он оставил в последний раз, когда я с ним работал. Если я правильно понял посыл автора предыдущего комментария, то в этот ряд можно так же добавить ещё и Bitrix, в котором globals повсеместно использовались ещё года так 2-3 назад и проблемы с поддержкой 7х версий были, не знаю как сейчас, благо ушёл с него и забыл как страшный сон. И я бы тоже хэйтил PHP, если бы знал только про Bitrix, потому что нормальным программированием там не пахнет: SOLID, DI — это не сюда.
sumanai
26.03.2019 21:51+1Bitrix, в котором globals повсеместно использовались ещё года так 2-3 назад
Там и сейчас без globals никуда (
Alexufo
27.03.2019 17:19вы не поверите, но клиентам все равно что вам нравится глобалс или нет. А кушать эту каку всегда есть кому когда за нее неплохо платят.
vdem
26.03.2019 23:42+2Достаточно глянуть исходники WordPress чтобы понять какое это г-но. Популярным он стал потому что альтернатив быстро запустить свой сайт в свое время не было, а сейчас многим дешевле и дальше с ним с кривыми плагинами мучиться, чем переписать всё под фреймворк. Вот если б они его полностью с нуля переписали. Показатель — хотя бы количество проектов на Upwork, где у заказчиков проблемы с WP (в моей ленте это где-то 30-40% от всех). Насчет Joomla не знаю.
Alexufo
27.03.2019 13:13Это не так. Он развивался в среде когда слева была джумла, справа modx, сверху ещё что-то, внизу тоже. CMS был зоопарк! Выбирать точно было из чего. Выстрелил он потому что думал об удобстве для потребителя, а не соблюдении паттернов ради паттернов.
Архитектурные ошибки именно и тянутся что о пользователе продолжают думать, чтобы не ломать обратную совместимость. Нет зоопарка версий. Есть строгие предупреждения перед обновлением, что сломается что-то такое. Пресс давно поддерживает json API, а его кривую архитектуру абстрагируют реактом. У меня подозрение, что в будущем однажды подменят ядро воссоздав идентичный API.
Там есть вещи дико выбешивающие меня, например, создание нового размера изображений заставит все загруженные файлы обрезаться в копию. Отсюда тонны лишних не используемых изображений.
vlreshet
27.03.2019 10:46Так а почему бы их не хейтить? В отличие от PHP, их качество никуда не выросло, как был там жуткий говнокод под капотом, так и остаётся.
Warrangie
27.03.2019 11:22Наверное потому что речь о «тех, кто в основном работал в єкосистеме WordPress и Joomla» именно в том контексте что эти люди больше всего хейтят пхп, а не про качество кода самих CMS?
Не скажу про вп, я один раз посмотрел на его код и больше никогда к нему не возвращался. Но под ждумлу я пишу последние два — два споловиной года, не только под нее, конечно, zf3, laravel, yii2 тоже использовал.
У джумлы есть проблемы только с доками из-за чего под нее сложно начать писать нормально. Но сам ее код не так уж и плох, вполне себе читается и дебажится. Проблемы есть, разумеется, но они со временем уходят.Alexufo
27.03.2019 13:16И как показывает практика, доля wp растет. Как растет Битрикс тоже страшно. При всем при этом первому прастительного ибо он бесплатный.
VolCh
27.03.2019 13:03Я лишь констатировал факт, что встречавшиеся мне продакшен-системы на WordPress и Joomla, которые пытались мне спихнуть на поддержку или развитие были написаны в стиле PHP4, если вообще не PHP3. PHP 5 и 7 в них поддерживались (хорошо если логи не засорялись depricated), но их фичи не использовались.
GreyStrannik
26.03.2019 22:29+2PHP хейтится за уровень разработчиков, за низкий порог входа. Это до сих пор так. Но в тот же Symfony порог входа весьма высок и средний уровень разработчиков на нём сильно выше, чем в среднем по PHP.
isden
27.03.2019 09:30Ну я застал проекты еще на PHP3 :|
И не то чтобы прямо хейт такой, просто открывая любой код на PHP, я всегда вспоминаю всю ту боль. Особенно в сравнении с другими ЯП.VolCh
27.03.2019 13:06+1Я тоже застал, но теперь открывая современный код на современном PHP испытываю удовольствие. Я закрыл психическую травму, нанесенную PHP3 :)
tehSLy
27.03.2019 11:07Так после 5.6 у него был тот самый прорыв на 7ку, а в итоге — ничего
пхп хейтят за его стремление сесть на оба стула в попытке «погони» (очень громкое слово, самому смешно) и за новыми фичами и за обратной совместимостью, в итоге получается что то среднее между ежом и ужом, вроде уже и не так колется, но все еще противно.
(Баги, висящие на багтрекерах годами, причем достаточно весомые, инертность языка, отсутствие конвенций в именованиях, очередности аргументов, все то, что уже проговорено 1000 и 1 раз)
((Сам сейчас веду проект на пхп, Laravel, все bleeding-edge версий, как был простым как палка, так и остался, за попытку отстрелить себе ногу никто ничего не скажет))
xPomaHx
27.03.2019 20:22-4Хз после js я вообще не могу больше писать на синхронных языках. Так же в php напрягает то что при наличии автоприведения типов есть разные операторы сложения и конкатенации, а еще больше бесит, это разные операторы доступа к элементам объекта, массива и статическим методам.
sumanai
27.03.2019 20:50+5разные операторы сложения и конкатенации
Странно слышать это от JSсника. Это же божественно. Нет ошибкам типа
2 + '2' 22 2 - '2' 0
vril
26.03.2019 15:02К слову Symfony 4 намного удобнее третьей ветки. Я PHP как язык не очень люблю, но Symfony 4 просто волшебная. Рекомендую.
sshikov
26.03.2019 15:36>правдиво для всех проектах на шестой Java
Вообще-то, даже Java 8 уже legacy. Как-то странно так вот сравнивать, если вы конечно имели в виду Java SE 1.6, вышедшую в 2006 кажется году.akurilov
26.03.2019 21:14Вообще как то всё очень поверностно. Ништяки Java — это не только исключения и возвращаемые типы. Автор, судя по всему, не имел вменяемого знакомства с Java
gdt
26.03.2019 21:56-1Неужели дженерики нормальные наконец завезли? Так-то в java отсутствует очень много ништяков, которые есть, например, в c#.
vics001
27.03.2019 23:51Дженерики «нормальные» это про что? Не испытываю проблем, что дженерики compile-time, да и есть конструкции для runtime, но на практике не возникает необходимости.
gdt
28.03.2019 08:01Если вы не испытываете проблем — это не значит, что их нет. Например, в проекте, над которым сейчас работаю, мы активно используем рефлексию и дженерики. Я не эксперт в java, но думаю, что в связи с type erasure повторить это на java очень сложно (если вообще возможно)
vics001
28.03.2019 17:35После 10 лет опыта, я встречал очень много и очень разные ситуации, чтобы сейчас сказать, что такой проблемы в большинстве случаев нет.
И да, рефлексия это уже плохо, потому что подрывает многие концепции compile-time проверок. Рефлексия должна использоваться в редких случаях.
Когда, в Java 1.5 вышли дженерики, кто только не говорил, что все это сделали лишь бы не менять байткод. На самом деле, байткод менять не нужно было и это сделано намерено. В Java давно существует RuntimeException TypeA[] a[0] = TypeB(); и его вполне можно отлично использовать. Так же есть Collections.checkedCollection, checkedMap… На пару проектов я использовал, но потом понял, что снижает performance и никаких багов в принципе не ловится, так что отказался.
Ответ один, лучше всего когда ошибки видны, чем раньше, тем лучше, а именно compile-time. Отлавливать что-то runtime моветон и в Java уже существует древняя проблема NPE как раз из-за недостатка compile time checks.
Давайте разбираться на конкретных примерах, что можно сделать лучше.gdt
28.03.2019 17:57Рефлексия не обязательно означает отсутствие compile-time проверок.
Давайте рассмотрим такой пример. Представим себе, что одному приложению необходимо генерировать и отправлять события. Получателю события уходят в формате, например, json, т. е. надо в коде как-то этот json формировать и отправлять. Событий конечное количество, но достаточно много, и периодически появляются новые и могут меняться старые. Набор атрибутов в целом у каждого события произвольный. Разные события могут обрабатываться по факту разными получателями, т. е. у них могут быть свои требования к формату значений. Типы данных значений в целом произвольные, есть вложенные структуры и коллекции.
А теперь внимание вопрос — как обеспечить типобезопасность таких событий? Делать руками json на каждый чих очевидно не вариант, передавать куда-то словарь <string, object> тоже не лучше — рано или поздно на проект придёт новый разработчик, напишет «null» вместо null или наоборот (и это самый простой кейс) и кто-то поимеет очень много головной боли.
А есть такой вариант — описывать события в виде контрактов (интерфейсов). Есть класс (покрытый тестами с ног до головы), который в runtime генерирует по интерфейсу реализации, умеет реализовывать коллекции (в том числе коллекции контрактов с коллекциями и тд), учитывает возможные атрибуты (которые определяют дальнейшие преобразования данных, например, формат даты/времени). Дальше такой объект передётся другому классу, который знает, что можно отправлять, а что нет, и который раскладывает объекты в нужное представление и отправляет получателю (это в первом приближении, всё гораздо более гибко). Таким образом, вы у себя в коде пишете что-то вроде
var evt = DataContract.Create<IMySuperEvent>(); evt.PropertyOne = 1; evt.PropertyTwo = "two"; evt.PropertyThree.Add(DateTime.Now); ... await _tracker.Track(evt);
Ничего лишнего, просто, удобно, типобезопасно, все довольны. Можно ли так сделать на java?transcengopher
28.03.2019 18:33Кхм. А если вот так?
IMySuperEvent evt = DataContract.make(IMySuperEvent.class); evt.setPropertyOne(1); // звиняйте, пропертей не держим evt.setPropertyTwo("Two"); // а это чтоб прокси колекций не делать, хотя тоже можно evt.addPropertyThree(LocalDate.now()); /*... Somewhere in a galaxy far away */ class DataContract { public static <T> T make(Class<T> cls) { return Proxy.newProxyInstance( cls.getClassLoader(), new Class<?> []{cls}, new DataPropertiesImplementation() ); } private static class DataPropertiesImplementation implements InvocationHandler { /* ... а вот тут ваш покрытый по самые помидоры тестами код, но на самом деле может быть и обёртка над HashMap ...*/ } }
Все методы интерфейса распознаются в соответствии с Java Beans 1.0 Spec, но в принципе реализация на усмотрение.
gdt
28.03.2019 18:43Неплохо вы меня уделали :) Это не совсем одно и тоже, но идея та же самая, согласен. Вообще дженерики просто первое, что в голову пришло. Вот например те же проперти или события, а точнее их отсутствие — встаёт непреодолимой преградой в освоении java. Я честно пытался несколько раз, но после C# совсем не то пальто.
transcengopher
28.03.2019 19:21Ну так и начинать стоило со свойств и событий, а то начали с прокси и рефлексии.
Причём, по моему мнению (с учётом ограниченных знаний, само собой), оба преимущества в экосистеме Java можно в определённых пределах имитировать, например, лямбдами.
И без свойств как таковых вполне можно обойтись — это скорее сахар над парой методов, чем именно что-то полезное до незаменимости. Хотя я вполне понимаю как такие мелочи могут портить впечатление от разработки, если уже привык. Я вот привык, что их нет, и просто делаю код. Когда их в Java добавят — порадуюсь, не добавят — ну что ж поделать, судьба такая.
Хотя мне и не нравятся соглашения о наименовании в C# — имя типа и имя метода должны быть различимы даже без подсветок синтаксиса, а в C# они именуются по одному и тому же шаблону; Но это вкусовщина, скорее) — я, впрочем, не буду отрицать в целом превосходство C# над Java — язык более молодой, смог учиться на ошибках и брать лучшее, плюс в раннем возрасте смог сбросить груз некоторых плохих решений в API стандартной библиотеки.
По этой же причине Ceylon, как я считаю, может превосходить их оба, только за счёт системы типов. Но так как я пока что не видел его подводных камней, — «может», не «превосходит».
vics001
28.03.2019 22:34То, что вы говорите, что у Generic не хватает описания конструкторов и их нельзя создать не выходя в рефлексию. Очень странно, но вот такой код распространен и дает отличный результат.
public <T> T newInstance(Class<T> cl) { /// reflection constructor } IMySuperEvent ie = newInstance(IMySuperEvent.class); ie.setProperty(...);
Недостаток что до сих пор это нельзя сделать без полной рефлексии и с compile time проверками, то есть нельзя написать <T has constructor ()>. С другой стороны, все очевидно, что для работы коллекции или сервиса нужен Class в runtime.
Property — вопрос исторический, их нет и уже огромная практика по get/set генерации. К этому можно быстро привыкнуть. И ко всем классам пишешь get/set, а если не пишешь подразумеваешь, что метод чисто data-structure. То есть либо везде, либо нигде, в принципе по количеству кода получается ненамного больше, но структурирует.
С появлением нормальных делегатов в Java 8 и Stream API, вопрос событий можно считать закрытым, потому что их очень просто писать с помощью делегатов и Lambda.
franzose
27.03.2019 00:12Вообще-то, даже Java 8 уже legacy
Однако большинство проектов всё еще на ней. И еще долго будут, судя по тому, как часто теперь выпускаются релизы.
Skerrigan
27.03.2019 06:39На сегодня уже доступен как пол-года новый LTS — v11. Проект, над которым работаю последние лет 5, уже на новом LTS.
В других фирмах, где серьезные Java-проекты, тоже переползают на v11.
sshikov
27.03.2019 11:28+1Дело в том, что автор пишет про Java 6, а не 8. Тех, кто сегодня сидит на 6, можно пожалеть, но уж точно не стоило сравнивать PHP сегодняшний, 7.х, с такой старой версией.
ZurgInq
26.03.2019 15:47+1Symfony 4:
- Документация местами ужасна, в том числе навигация по документации.
- Конфиги, конфиги и ещё раз конфиги. С десяток конфиг файлов в установке с нуля. Куцая документация добавляет боли.
- Аннотации — в сложных случаях вырождаются в программирование на комментариях.
- Сплошная магия во всех ключевых компонентах (сериализатор, валидаторы, секьюрити) — одна не осторожная строчка в конфиг файлах, или неправильно написанная аннотация, и без пошаговой отладки уже не разобраться. И собственно сами "магические" методы, которые так ругают в других фрэймворках, их здесь кажется даже в разы больше чем в Laravel, только они спрятаны более тщательно.
EvgeniiR
26.03.2019 17:22-3Конфиги, конфиги и ещё раз конфиги. С десяток конфиг файлов в установке с нуля. Куцая документация добавляет боли.
Напишите сходу 10 конфигов? Где их меньше? Какие альтернативы конфигам предлагаете?
Аннотации — в сложных случаях вырождаются в программирование на комментариях.
В каком месте Sf4 принуждает вас юзать аннотации?
Сплошная магия во всех ключевых компонентах (сериализатор, валидаторы, секьюрити) — одна не осторожная строчка в конфиг файлах, или неправильно написанная аннотация, и без пошаговой отладки уже не разобраться
см п.1ZurgInq
26.03.2019 17:52+1Напишите сходу 10 конфигов? Где их меньше? Какие альтернативы конфигам предлагаете?
Convention over configuration. Можно посмотреть в том числе на lumen, или любой другой api фрэймворк.
В каком месте Sf4 принуждает вас юзать аннотации?
Официальная документация и инструменты (в том числе кодогенерации) по умолчанию форсят аннотации. Можно перейти с программирования на аннотациях на программирования через конфигурации, но легче от этого не станет, yml файлы ни чем не лучше аннотаций. Последний вариант — конфигурация через php код, тут хотя бы будут подсказки по коду.EvgeniiR
26.03.2019 18:17тут хотя бы будут подсказки по кодa
У меня и в Аннотациях подсказки работают, так что не вижу разницы(да и с конфигами, вродь, не возникает проблем), а если там вот такое:
$app->get('{id}/posts/{postId}', ['uses' => 'UsersController@getUserPost', ]);— нет по сути разницы где это описывать, автокомплита ни там ни там не будет
Официальная документация и инструменты (в том числе кодогенерации) по умолчанию форсят аннотации.
Точно так же они форсят бездумно пихать геттеры и сеттеры в сущности, класть их все кучей в App\Entity etc., что не мешает всего этого не делать. В принципе не самый приятный момент, но тем не менее вполне неплохая кодогенерация есть, Laravel с кодогенерацией из коробки всё ж не лучше, хоть и не плох.
tendium
26.03.2019 21:57+4тут хотя бы будут подсказки по кодa
PhpStorm с соответствующим плагином всё нормально подсказывает.
franzose
27.03.2019 00:34Аннотации — в сложных случаях вырождаются в программирование на комментариях.
А это всё потому, что, в отличие от Java, в PHP аннотации не являются частью языка. К сожалению. В некоторых случаях их удобно использовать «на месте». Например, в контроллерах.
franzose
27.03.2019 00:37+1Конфиги, конфиги и ещё раз конфиги. С десяток конфиг файлов в установке с нуля. Куцая документация добавляет боли.
Ровно то же самое во всех остальных фреймворках. А как иначе вы будете настраивать под свои нужды отдельные компоненты?
TiGR
28.03.2019 15:17+3Конфиги, конфиги и ещё раз конфиги. С десяток конфиг файлов в установке с нуля. Куцая документация добавляет боли.
Установка с нуля — конфигов 8 штук, а по сути 5 (3 ещё — отдельная настройка окружений dev/test). Строк не комментариев, не пустых — 35. Столько же строк — комментариев. Там всё расписано где и что означает.
Сплошная магия во всех ключевых компонентах (сериализатор, валидаторы, секьюрити) — одна не осторожная строчка в конфиг файлах, или неправильно написанная аннотация, и без пошаговой отладки уже не разобраться.
Это не магия, это скрытые под капот заморочки. Тут варианта два — либо самому обо всём этом заморачиваться, либо скрыть за слоями абстракций, но в результате, можно в редких случаях получить сложные ситуации.
Ну и потом. аннотации не обязательны, можно жить без них. С доктриной сложнее, а что в Symfony всё можно сделать и без аннотаций.
И собственно сами «магические» методы, которые так ругают в других фрэймворках, их здесь кажется даже в разы больше чем в Laravel, только они спрятаны более тщательно.
Ну вот это вы совсем зря.
СчитаемLaravel:
$ git clone git@github.com:laravel/framework.git laravel && cd laravel $ grep -P 'function __(call|get|set|isset|callStatic)\(' src -R | grep -Poi '__[a-z]+' | sort |uniq -c 41 __call 6 __callStatic 14 __get 8 __isset 6 __set # А если учесть, что там ещё магия часто вынесена в трейты, то надо добавить ещё: $ grep -PR 'use .*\\(Macroable|ForwardsCalls|Fluent)' src | grep -Poi '[a-z]+$' | sort |uniq -c 11 Fluent 10 ForwardsCalls 33 Macroable
Symfony:
$ git clone git@github.com:symfony/symfony.git && cd symfony $ grep -P 'function __(call|get|set|isset|callStatic)\(' src -R | grep -v 'Tests' | grep -Poi '__[a-z]+' | sort |uniq -c 9 __call 4 __get 3 __isset 2 __setkpbsod
26.03.2019 16:11PHP не очень люблю, но приходится c ним работать. Так же приходится работать с Kotlin.
Сравнивая два этих языка могу сказать, что в мире PHP ещё очень многое предстоит сделать.
Мне вот, например, очень сильно не хватает:
- дженериков (раз уж язык начал стремиться в статическую типизацию);
- нормальных коллекций и мэпов;
- адекватного синтаксиса для лямбд;
- нормальных аннотаций (а не вот эти вот дурацкие комментарии);
- поддержка UTF-8 по дефолту для всех функций;
- производительность хромает, нужна производительность получше;
- composer ужасен, в сравнение с Gradle, по крайней мере.
Ну и всякого другого по мелочи.
В Symfony не нравится зашкаливающее количество всяких конфигураций и неочевидных моментов. В это плане Spring Framework (особенно в связке со Spring Boot) намного проще.AlexLeonov
26.03.2019 19:25В PHP нет никакой статической типизации и никогда не будет. Откуда?
Статическая типизация — определение и контроль типа значения и/или переменной при компиляции.
В PHP контроль типов принципиально рантаймовый. И никогда иным не был.
Откуда хоть вы этот миф берете, про «движение к статической типизации»?kpbsod
26.03.2019 20:22Например, как вы в рантайме вернёте не string из функции ниже? Ни это ли элементы статической типизации?
class A { function f(): string { return new A(); } } echo (new A())->f();EvgeniiR
26.03.2019 22:23+4Статическая типизация — это когда типы известны до запуска кода, т.е. не про рантайм. В PHP же все проверки по прежнему идут в рантайме, и если что-то не так, ошибку вы словите в уже работающей системе.
sumanai
26.03.2019 22:37Точнее по умолчанию PHP молча приведёт тип к требуемому.
EvgeniiR
26.03.2019 22:40+2Это уже следствия слабой(нестрогой) типизации, и не все типы конвертируются.
Soo
27.03.2019 06:55Я вот этого не понимаю. Когда работают на С и иже с ними все страдают со строгой типизацией и пытаются постоянно менять типы. Когда переходят на языки с нестрогой типизацией — РНР или JS, начинают хаять эту нестрогую типизацию и сочиняют всякие TypeScript и подобное.
Не знаю, мне строгость типизации проблем не доставляла, может я уже привык просто ко всяким примочкам приведения типов, что я уже и не замечаю каких-либо неудобствEvgeniiR
27.03.2019 13:15Нестрогая типизация повышает риск возникновения багов, которые на так уж и просто отловить
может я уже привык просто ко всяким примочкам
Хорошо если привыкли, но если пробежаться по типичным проектам можно увидеть как люди символьную строку с int сравнивают через нестрогое сравнение0x131315
28.03.2019 11:17Нестрогая типизация в интерпретируемых языках более удобна, ИМХО.
Позволяет срезать углы.
Ты пишешь какой-то код на языке со строгой типизацией, и внезапно выясняется, что в разных ситуациях возвращаться может несколько типов. Опа, неожиданность.
Теперь тебе нужно проверить все-все-все эти ситуации, для каждой из них написать копию метода со своими типами, плюс валидатор, который проверяет эти ситуации и выбирает метод, и… все равно получить ошибку, потому что учел не всё. А всё учесть очень сложно.
Огромный минус — вот эти вот танцы вокруг типов и, как следствие, необходимость плодить и поддерживать много почти одинакового кода, следить за его синхронизацией, вносить правки в каждую копию кода (забудешь же, т.к. в каждой логика немного отличается), и тестировать отдельно каждую копию — хороший источник человеческих ошибок, невнимательности.
На интерпретируемом языке с динамической типизацией проще.
Если видишь, что код простой — объявляешь возвращаемый тип, и ошибку получаешь только если в код передали вообще какую-то дичь, и так и так надо падать и разбираться что это было.
А если видишь, что ситуаций может быть много и возвращаемых типов несколько — не объявляешь возвращаемый тип, но добавляешь комментарии и, ориентируясь по ним, в методы, которые используют результат работы кода, добавляешь соответствующие проверки типов, если нужно, или описывашь логику так, чтобы она работала сразу со всеми типами, что часто раздувает код всего на пару строк.
Нет дублирования кода под разные типы — правки почти всегда согласованы, и делаются в одном-двух местах, а не в десятке.
Как итог — да, вероятность поймать магическую ошибку выше, чем в языках со строгой типизацией, т.к. свободы больше.
Но количество ошибок намного ниже, и код намного чаще работает нормально, чем нет. В языках строгой типизации ты сначала соберешь почти все ошибки, прежде чем код вообще запустится.
Код выходит более чистый, простой, его меньше (нет дублирования), его проще понять.
Как минус: без теста трудно сказать, будет ли код работать. Но для этого есть юнит-тесты.
Как плюс: работающий код можно писать сразу.
Написал — посмотрел какие косяки — поправил, посмотрел — поправил.
Очень быстро все критичные ошибки выловил — код работает, ушел в продакшн. Потом по репортам фиксишь мелкие косяки.
Более быстрая и интерактивная разработка получается: код адаптируется под задачу и вместе с задачей.
andreymal
28.03.2019 11:37+1для каждой из них написать копию метода со своими типами
много почти одинакового кодаДженерики, интерфейсы и трейты — не, не слышали?
SerafimArts
28.03.2019 14:37Дженерики, интерфейсы и трейты — не, не слышали?
Ну, допустим, в Go не слышали :Dandreymal
28.03.2019 14:41Ага, я подумывал ответить что-то в стиле
«Ловите гошника!», но решил воздержаться)
Но в Go 2 вроде обещали какие-то дженерики (но это не точно)
syfim
27.03.2019 12:40Ошибка, конечно, случится в рантайме. Но вот шанс её возникновения будет куда ниже — ide подсветит ошибки по невнимательности
Jouretz
26.03.2019 22:56Хм…
<?php declare(strict_types = 1); class A { function f(): string { return new A(); } function __toString() { return "5"; } } echo (new A())->f();
Fatal error: Uncaught TypeError: Return value of A::f() must be of the type string, object returned in /in/OWFlL:6
ok, пусть это была опечатка
<?php declare(strict_types = 1); class A { function f(): string { return (string) (new A()); } function __toString() { return "5"; } } echo (new A())->f(); echo "\n\r"; echo ((new A())->f()) + "2";
Output for 7.3.3 | took 12 ms, 14.52 MiB
5
7
3v4l.org/2KdVU
Тайпхинтингу до статической типизации ещё жить и жить.EvgeniiR
26.03.2019 23:01+1Тайпхинтингу до статической типизации ещё жить и жить.
Как ваши примеры связаны со статической типизацией?
Автокаст типов — последствия слабой(нестрогой типизации). А типы возвращаются верные(функция возвращает строку), только опять же это не статическая типизация, т.к. типы проверяются в рантаймеJouretz
26.03.2019 23:06-1Дык никак =_=
В комментарии выше говорится что тайпхинт — элемент статической типизации.
По факту он никак не мешает переменным менять тип в процессе исполнения и, как я понимаю, выполняет только функцию создания видимости порядка в хаосе автоприведения типов.
AlexLeonov
27.03.2019 13:58Нет, это не статическая типизация, это динамический контроль типов. Вы слегка путаетесь в терминах.
xotey83
28.03.2019 15:08+1Это не элементы статической типизации. Статическая типизиция подрузамевает, что все типы всех переменных известны по время компиляции в поэтому в рантайме проверять типы нет необходимости.
В PHP это используется динамический контроль типов, да то они проверяются лишь во время вызова функции и возврата значения. Пример ниже нормально работает для PHP, но при этом он был бы недопустим для языка со статической типизацией:
function foo(int $bar) { $bar = 'baz'; // упс! взяли аргумент, который объявлен как int, и положили в него строку }
Gemorroj
26.03.2019 20:58+14composer ужасен
вот это заявление) вроде как наоборот, считается великолепным пакетным менеджером. что не устроило в композере?
Tatikoma
27.03.2019 12:38Если придираться, то он довольно медлителен. А вообще да, с появлением composer жизнь стала сильно лучше.
symbix
27.03.2019 15:59он довольно медлителен
Медленный там только composer update (потому что реализован по уму и там внутри настоящий SAT Solver), но update нужен раз в полгода. Все остальное весьма шустро.
Tatikoma
28.03.2019 12:22Вы не работали с yii2, когда он требовал bower-asset… Как я понимаю там получался приличный список пакетов/зависимостей, обработка которого и сжирала тонну времени.
molchanoviv
26.03.2019 21:10+2Я вот тоже пишу на пхп и котлине. Да конечно котлин как язык поприятнее пхп, но вот сравнивать композер и грэдл по меньшей мере странно. Композер это менеджер пакетов, притом очень хороший, а грэдл это таск менеджер, там и установка пакетов и билдскрипты и линтеры и еще куча всякой всячины.
msatersam11
27.03.2019 09:39И… что в итоге должно получиться?
Очередная джава, плюсЫ или шарп? -Постой-ка, так они уже есть…
zim32
26.03.2019 16:19+1Пхп красава, он как гадкий утенок. Пока его все поливали бурой массой, он взял и вырос в красавца.
BruAPAHE
26.03.2019 16:54Шел 2019 год. Люди начали понимать, почему все пишут на пыхе
YemSalat
27.03.2019 08:56> все пишут на пыхе
Смелое заявление :)Djeux
27.03.2019 11:17Если брать область веба, то 80%. Довольно значительная часть.
YemSalat
27.03.2019 12:19Откуда статистика?
Djeux
27.03.2019 12:20YemSalat
27.03.2019 13:53Вот вам цитата:
According to W3Techs’ data, PHP is used by 78.9% of all websites with a known server-side programming languagе
Т.е. это данные по «веб-сайтам» которые сканирует W3Tech. В таком же стиле можно утверждать что 99.9% сайтов используют javascript, поэтому он перспективнее.
В общем с реальным положением дел имеет мало общего.
Для более наглядной картины («все пишут на пыхе») лучше посмотреть рынок вакансий (нормальных вакансий) в сфере веб-раразботки, там пхп далеко не 80%sumanai
27.03.2019 20:43В таком же стиле можно утверждать что 99.9% сайтов используют javascript, поэтому он перспективнее.
JS замены нет, нет конкуренции языков, отсюда и результат. У PHP море конкурентов.
IvanNochnoy
27.03.2019 15:04Если брать область Веба, то из этих 80% сайтов на Пыхе, 90% — это бложики на Wordpress с посещяемостью 1 человек в месяц, т. е. фактически одна программа, растиражированная миллионными экземплярами. Судя по той же статистике, Java вообще в заднице со своими 2-3%, одако эти 2-3%, собирают у себя больше посещений, чем все сайты на Пыхе вместе взятые. Сто раз уже говорил, что смотреть нужно не по количеству сайтов, а по количеству рабочих мест.
sumanai
27.03.2019 20:45+1одако эти 2-3%, собирают у себя больше посещений, чем все сайты на Пыхе вместе взятые
VK и Facebook так или иначе используют PHP, не зря же оба пишут свои инструменты для него. А как там у них с посещаемостью? А то я соцсетями не пользуюсь.
samizdam
27.03.2019 23:59Вот не надо. Не бложиками едиными.
Из мирового топ-20 алексы навскидку Wikipedia, FB, VK достоверно используют php как основной язык.
Badoo, кстати, к поднятому выше вопросу о нормальных вакансиях: tech.badoo.com/ru/vacancies
Запилить малый/средний/крупный интернет-магазин на чём-то кроме php, с точки зрения бизнеса выглядит той ещё авантюрой.
Ну и конечно, наш всеми любимый уютный Хабр)
Так что с трафиком все нормально.
По количеству рабочих мест, можете посмотреть сами тоже всё в порядке.
Можно убедиться в этом посмотрев кол-во вакансий на любом ресурсе. Не забывайте, что в языках где рабочих мест будто бы больше (java например), не только веб, и сменить специализацию порой сложнее чем язык. А php — исключительно веб.
paco
26.03.2019 16:59Шел 2019 год, а сообщество PHP до сих пор не обновили PHP.net и не написал нормальную документацию.
arkamax
26.03.2019 17:51Пару лет назад на ZendCon Сара Големон не особо скрывала, что в документации дыры и волонтеры для их починки *очень* приветствуются. По-простому говоря, если есть руки и знание языка — ради бога приходите. Возможно все же есть какой-то сравнительно жесткий входной ценз для волонтеров.
michael_vostrikov
27.03.2019 12:00Меня больше удивило, что обсуждение разработки ведется через рассылку по email всем кому надо и не надо. И отдельно существует веб-интерфейс к этим письмам. Самый популярный язык для веб-разработки, можно же было какой-нибудь форум сделать с подпиской на конкретные темы.
samizdam
28.03.2019 00:02Я просто оставлю это здесь: habr.com/ru/post/314084
michael_vostrikov
28.03.2019 00:28Ну я бы наверно согласился, что для Linux это в некоторой степени оправдано, но блин для языка веб-разработки?)
s0lar
26.03.2019 17:12Обожаю Симфони 4.
Но если ты попадаешь на стэковерфлоу с вопросом о связи двух и более Entity, то разбор превращается в ад.
В итоге ты скролишь огромные простыни с описанием сущностей.GreyStrannik
26.03.2019 22:24+3В документации Doctrine есть хорошие примеры и сложные случаи, обычно их хватает. Не хватает — можно и на StackOverflow.
arkamax
26.03.2019 17:59+14У меня есть полдесятка знакомых сеньоров с 5+ годами опыта в своей области (не-PHP), которые немного не в курсе выхода версии 7.0 (некоторые про 5.0 не слышали). Когда говорю, что у меня 90% работы на РНР — сочувствующая усмешка. Потом они слышат о наличии вещей типа интерфейсов, жесткой типизации и встроенной крипты, и отвисшие челюсти можно снимать на видео. Контрольный в голову — «а еще на РНР было рассчитано 40+ тысяч операций на глазах, и ни один не пострадал» (было у меня как-то несколько проектов по медицине). Удивляет, что современные профессионалы продолжают высказывать безапелляционное мнение при отсутствии адекватной информации о сути дела.
GrigoryPerepechko
27.03.2019 05:26+1Встроенная крипта — это вы про вызовы сишных либ?
Жесткая типизация — это про тайп хинты?
Интерфейсы — это те которые определяют только имя метода и кол-во аргументов, но не их типы?
Про расчет — позабавили. Я погуглил про 64 битные числа, и оказывается что на PHP 5 на винде они вообще недоступны, а на линуксе необходима 64битная машина (!). Потом я прочел совет использовать BCMath, и увидел в сигнатурах функции сложения чисел в аргументах строки, Карл! Еще в 7 классе многие писали длинную арифметику на паскале на массивах (байтов, либо кто покруче интов). А тут строки.
Да, можно и на брейнфаке писать работающий код, но для вычислений я бы не использовал язык где проблемы с базовыми вещами вроде примитивных типов.
Как способ быстро добиться результата (http ответа с html, либо с json на базе ответа из БД), наверное PHP удобен, но не потому что язык хорош, а потому что одну и ту же задачу на нем решали миллионы раз и написали понятных оберток. Как язык (да, тут подразумевается язык общего назначения) — это мусор какой-то и писать на нем расчет медицины (что бы это не значило) не стоит.
Compolomus
27.03.2019 10:00+1Интерфейсы с типами же. Типы аргументов и тип возвращаемого значения, просто не все делают строгие интерфейсы
arkamax
27.03.2019 18:57+3Ну вот опять.
Встроенная крипта — это вы про вызовы сишных либ?
Большая часть функциональности программ в user mode — это вызовы либ (начиная от glibc на GNU), это если вы конечно не хотите изобретать велосипеды. Я не столько про это, сколько про sodium в PHP 7.2. В отличие от упомянутого ниже (и удаленного из 7.2) mcrypt:
1. Sodium куда проще правильно готовить. Он не позволяет использовать многие нестойкие / ослабленные режимы типа AES-ECB — от чего страдал mcrypt. Огромная часть атак на методы шифрования выполняется на некорректное их использование, а не на основополагающие алгоритмы. При этом большая часть разработчиков не заморачивается деталями, и использует первый же метод из документации. При этом если голова на месте — пожалуйста, используй openssl и шифруй так, как заблагорассудится. По факту имеем систему, более подходящую для разработчиков, не имеющих базовых знаний по криптографии.
2. Sodium влит в ядро. Я только что проверил — на том же EasyApache нет опции, чтобы его отключить (на mcrypt — есть), на основной платформе (Linux) он отключается только опцией компиляции (а не строчкой в конфиге). Это дает основания ожидать, что он будет доступен на подавляющем большинстве хостингов, в отличие от mcrypt — что заставляло городить тот же AES/Rijndael в нативном режиме.
Жесткая типизация — это про тайп хинты?
Намек: hint на английском — намек. На данный момент это уже не намек, а декларация: «Type declarations were also known as type hints in PHP 5.» — это что касается аргументов функций / методов. Декларативное объявление типа аргумента выбросит исключение при вызове с несовместимым аргументом. Несколько моментов:
1. Формально это не жесткая типизация на уровне хранения данных. Во многих других ЯП это куда строже — однако здесь на уровне исходного кода получается то же самое как минимум в контексте вызова методов / функций.
2. Типы переменных пока декларировать нельзя, декларацию типов свойства объектов добавят в PHP 7.4. При этом никто не мешает повесить getters/setters на свойства и типизировать их аргументы.
Интерфейсы — это те которые определяют только имя метода и кол-во аргументов, но не их типы?
Уже давно определяют (при желании). Несовпадение по типам в реализующем классе дает исключение.
Я погуглил про 64 битные числа, и оказывается что на PHP 5 на винде они вообще недоступны
Простите, и что? При разработке приложений обычно ориентируются на наиболее массовые системы. 1. PHP на Windows — точно не самая массовая система. 2. Поддержка PHP 5 даже на уровне обновлений безопасности прекращена в прошлом году.
а на линуксе необходима 64битная машина (!)
1. Насколько вы знакомы с современным рынком хостинга? Тот же RHEL/CentOS с версии 7 поддерживает только 64-битную архитектуру как минимум на Интелах, процессора имеют 64-битные расширения уже много лет.
2. Почему обязательно использовать 64-битные числа — на всякий случай?
Потом я прочел совет использовать BCMath, и увидел в сигнатурах функции сложения чисел в аргументах строки, Карл!
Это декларация аргумента — просто чтобы загнать в движок число произвольной длины (arbitrary precision). Да, вы можете запихать туда нечисленное значение — не надо этого делать. Альтернатива — использовать указатели на блок памяти (небезопасно, их в PHP просто нет в обычном понимании), или другие методы работы с памятью. Строки в PHP при этом вполне работоспособны для переноса числовых данных, и не только их.
Как язык (да, тут подразумевается язык общего назначения) — это мусор какой-то и писать на нем расчет медицины (что бы это не значило) не стоит.
Ваше мнение мне понятно, и я его уважаю. Позволю себе изложить некоторые факты:
0. Требования к системе включали доступность расчетов на сайте. Это резко уменьшало количество доступных, сравнительно легко обновляемых и поддерживаемых реализаций, не требующих сращивания бульдогов с носорогами (см. ниже про MatLab)
1. «Расчет медицины» бывает разный. В моем случае (расчет интраокулярных операций) стандартной точности PHP (сейчас не помню дефолты в 5-й версии, ЕМНИП 12 или 14 знаков после запятой, в 7.3 — 14) было более чем достаточно. BCMATH приходилось использовать лишь в единичных случаях — в остальных с лихвой хватало обычных float.
2. После любых изменений подобного кода в обязательном порядке прогоняются регрессионные тесты. В моем случае они выполнялись на нескольких десятках (сотнях) тысяч расчетных кейсов, описывающих оптико-биологические параметры человеческого глаза. Результаты должны совпадать с контрольными расчетами (мы использовали MatLab) до офтальмологической клинической значимости (плюс-минус 1/10 диоптрии). За всю свою практику расхождений по регрессионным тестам больше чем в 6 знаке после запятой я не видел — и это были пограничные кейсы. Это разница с клинической значимостью на 5 порядков… Карл. Позволю себе утверждать, что конкретные требования были более чем закрыты.
3. Как-то мне пришла в голову мысль, что гонять регрессии на таблице кейсов неспортивно, и я запустил расчеты по всему диапазону параметров (глубина передней камеры от 0 и выше, в числе других извращений). Некоторые результаты оказались «нестандартными». Когда мой шеф (хирург-офтальмолог-математик) увидел эти расчеты, он сказал, что использованные параметры не описывают систему зрения биологически возможного человека (ну не бывает у людей глаз 5 сантиметров в диаметре).
4. Мы рассматривали вариант гонять вычисления напрямую на движке MatLab — но не потому, что не устраивала точность PHP, а чтобы сократить время на конверсию методик. Этот подход было признан неэффективным как с инженерной точки зрения, так и с точки зрения поддержки и развития системы.
5. Некоторые конкурирующие системы расчетов были написаны… на Excel. При этом их точность страдала не от точности управления данными итп, а от кривых/упрощенных методик.
6. Для полной ясности: десятки тысяч реальных операций было посчитано и выполнено. У меня лежат письма от хирургов, у которых люди плакали от счастья, в первый раз за 10 лет увидев мир без очков толщиной с бутылочное донышко. У меня язык не повернется сказать, что это было сделано «не по фэншую». Негативных последствий, вызванных расчетными методиками, замечено не было, подавляющее большинство введенных изменений относилось к обновленным клиническим рекомендациям от производителей аппаратуры.
Вывод — был выбран инструмент для решения задачи, выбор был обоснован и подтвержден многочисленными проверками, и адекватность выбора была подтверждена массой реальных кейсов. ИМХО ваша фраза про «не стоит» — это широкое утверждение, под которым я не вижу точного обоснования, подтвержденного детальными расхождениями с требованиями конкретных задач. Как результат, ваш комментарий лишь подчеркивает мой тезис о том, что прежде чем называть язык мусором, неплохо бы собрать информацию о четко описанных косяках из реальной жизни, которые вы собираетесь критиковать.
YemSalat
27.03.2019 08:46> встроенной крипты
В пхп7 есть «встроенная крипта»? Что?VolCh
27.03.2019 13:25Стандартные расширения для работы с криптографией
YemSalat
27.03.2019 13:48Ну если это называть «встроенной криптой» — то даже не знаю :)
И не получится ли с этой «встроенной» темой как получилось с `mysql_*` через n лет?vlreshet
27.03.2019 14:12И не получится ли с этой «встроенной» темой как получилось с `mysql_*` через n лет?
Так а что с mysql_ не так, поддержка MySQL не исчезла же совсем, она просто переродилась в более совершенные mysqli и pdo. Чем плохо?YemSalat
27.03.2019 14:19Ну я к тому что вы уверены что на новичков, использующих текущую реализацию, потом не будут кричать «эй, ты что дурак?! зачем юзаешь crypta_, надо же юзать cryptai_ или PDО!!»
vlreshet
27.03.2019 14:51Ну будут кричать, и что? Суть то останется то же самой — у PHP будет встроенное расширение от криптографии. То о чём вы беспокоитесь — это уже проблемы обратной совместимости, это немного другая песня
VolCh
27.03.2019 14:51Как бы уже кричат :)
YemSalat
28.03.2019 17:15Меня уже заминусили, но моя основная мысль была в том что, возможно, не стоит все встраивать в сам язык, чтобы потом нe было проблем в стиле «да, это встроено, но не вздумай использовать!!!»
Т.е. «встроенная крипта» — это минус, а не плюс.
isden
27.03.2019 14:56> И не получится ли с этой «встроенной» темой как получилось с `mysql_*` через n лет?
Это уже было.
berezuev
26.03.2019 18:06+18Всем тем, кто ругает рнр и Симфу за аннотации, конфиги и магию:
Перестаньте уже использовать Sublime Text и Notepad++ для редактирования PHP. Поставьте PHPStorm и к нему 3 плагина: PHP Annotations, Symfony plugin и EA Inspections, и пользуйтесь всеми благами IDE (инструменты рефакторинга, навигации по коду, встроенные инспекции и т.д.).
И да пребудет с вами «shift shift».sumanai
26.03.2019 21:57-6Поставьте PHPStorm
Его купить для начала надо. И он считается не самым быстрым инструментом.
iproger
26.03.2019 23:07+3Около 80 в год, да. И комп нужен с i7/r7 чтобы нормально было. Зато очень удобно.
sl0
27.03.2019 02:51Работаю на i3 — полет нормальный. Обычно тормоза происходят из-за каких-нибудь кривых плагинов.
trawl
27.03.2019 06:58Celeron G3930. Полёт нормальный.
iproger
27.03.2019 07:48Видимо надо менять, мне бракованный попался. Проект в реиндексе загружает 9900k на 100% в течении 15 секунд.
trawl
27.03.2019 07:54Возможно, SSD поможет (или уже)?
У меня SSD и 8Гб оперативы, шторм установлен нативно (не через snap) на linux mint 19.1.
За загрузкой процессора, конечно не наблюдал, но не припомню, чтобы были безбожные тормозаiproger
27.03.2019 08:14У меня не совсем обычный случай. На компах стоят ssd, но проект находится на соседнем через гигабитный lan. Phpstorm ругается что соединение медленное, хотя терпимо, на уровне hdd.
tendium
27.03.2019 08:15Почему проект не может быть на вашем компе в локальном каталоге?
iproger
27.03.2019 19:36Потому что лучше пожертвовать скоростью в phpstorm чем чтобы проект работал медленно из-за сетевых задержек.
VolCh
27.03.2019 19:51Не знаю как остальные более-менее популярные IDE, но PhpStorm и ко явно предупреждают, что лучше использовать синхронизацию чем монтирование
michael_vostrikov
27.03.2019 20:18Обычно делают deployment через sftp при сохранении файла.
iproger
27.03.2019 21:14У меня локальный проект. На сервере Ubuntu с samba, на пк винда.
michael_vostrikov
27.03.2019 21:49+1Вы клонируете репозиторий на свой компьютер, в локальную ФС. Настраиваете в PHPStorm секцию deployment, я вот там сейчас вижу в числе прочих варианты "SFTP" и "local or mounted folder". При сохранении он загружает файл на удаленный сервер. Вы получаете плюшки локальной работы с файлами и удаленных сервисов типа компиляции или веб-интерфейса. Обычно параллельно открыто соединение к серверу по ssh. Можно коммитить с локальной машины. Если репозиторий через интернет недоступен, делаете проброс портов через putty или ssh в git bash, соответственно меняете настройки системы контроля версий.
iproger
27.03.2019 22:29Я понял. Интересная фича.
Не уверен что мне подойдет. Я вот привык работать с файлами напрямую. Если сервер что-то написал в лог то хочу сразу видеть что. Или сгенерировал файл. Или еще что.
Мне бы синхронизацию в обе стороны, но пока не нашел такого решения чтобы взять и использовать.VolCh
27.03.2019 22:31realsync смотрели?
Source
28.03.2019 00:39А Вы ещё удивлялись откуда хейт берётся… Люди всерьёз обсуждают, как из IDE редактировать файлы напрямую на боевом сервере :facepalm:
michael_vostrikov
28.03.2019 00:45Какой боевой сервер, вы о чем?
Source
28.03.2019 23:10О сервере, который обслуживает пользователей проекта. О чём же ещё...
michael_vostrikov
29.03.2019 07:18Ну а люди всерьёз обсуждали сервер для разработки, а не тот, который пользователей обслуживает.
Source
29.03.2019 10:24Каждому программисту отдельный сервер для разработки? Или вы только случаи команды из одного человека рассматриваете?
michael_vostrikov
29.03.2019 10:49Зачем отдельный-то? Я же ниже написал — создается папка, настраивается домен. Разработчик редактирует код на одной машине, а работает он на другой. В чем вообще необходимость локально его запускать?
michael_vostrikov
28.03.2019 00:06Так если ssh открыт, какая разница? На сервере работаете через консоль, логи проверяете стандартными командами сервера (grep, tail). Разница только в расположении исходников. Если надо что-то просмотреть локальными инструментами (ну да, mcedit не всегда хватает), можно тоже скачать на локальную машину.
kivsiak
28.03.2019 00:17-4Вот почему пхпшники удивляются почему их за программистов не считают. Вот поэтому:
Вместо цикла
— пуш в репо
— прогон тестов
— сборка пакетов или образа
— деплой пакета или образ
вы до сих пор напрямую или опосредованно правите фаилы на сервере и не понимаете в чем ваша проблема
Что обидно есть и грамотные инженеры что практикуют правильные подходы. Но мнение о пхп культуре разработки и языке в целом составляют не по ним.michael_vostrikov
28.03.2019 00:29+1Это вы не понимаете, что такой проблемы нет. Прочитайте всю ветку пожалуйста.
kivsiak
28.03.2019 00:37>Обычно делают deployment через sftp при сохранении файла.
Я читаю вот это и меня бомбит.michael_vostrikov
28.03.2019 00:38Я и говорю, прочитайте всю ветку. Хотя бы комментарий, на который я отвечал.
kivsiak
28.03.2019 00:56-1>Обычно делают deployment через sftp при сохранении файла.
это тот полностью коммент на который я ответил.
Я перечитал внимательнее ветку. Меня еще больше момбануло. 2018 год править исходники в стевой шаре!
Автор из кожи вон лезет показывая что пхп наконец то стал адекватным языком, приводит правильные аргументы, и тут читать вот это!
michael_vostrikov
28.03.2019 01:08Блин. Есть настроенный для разработки сервер, с нужными ресурсами для запуска приложения и DNS именами. Есть машина разработчика, к которой вообще никаких требований нет, ни по ресурсам, ни по сетевой конфигурации. Разработчик может редактировать файлы на настроенном сервере через консольные редакторы, может монтировать удаленную ФС на локальную машину со всеми недостатками по скорости, а может загружать на этот сервер файлы при сохранении, при этом сохранять возможность работать с проектом локально, в том числе с системой контроля версий. Вы какой вариант выбираете и почему?
kivsiak
28.03.2019 01:35Круто. Реально круто что вы такое настроили. Лет так 15 назазад работал я в такой конторе. Не удивлюсь что до сих пор работает. Тогда это правда от бедности практиковали. Да и сейчас это все локально 1 скрипт запустить…
Вот только вопрос вы задали странно. Между чем я должен выбирать, уточните плз. Заодно прикиньте это точно к контнексту не ветки но хотя бы последних 5 постов относится?michael_vostrikov
28.03.2019 01:43Это стандартный вариант, когда на личной машине разработчика меньше ресурсов (или настроек сети), чем нужно для приложения. Какой такой скрипт вы имеете в виду, который добавляет ресурсов машине? Варианты, между которыми выбирать, я уже написал. Еще раз, к деплою на боевой сервер это никак не относится.
kivsiak
28.03.2019 02:39Если мне надо развернуть локальное окружение я использую докер — стандарт де факто в 2019 году.
Если вдруг задача требует мощностей что я не могу обеспечить локально, я тот тоже докер разверну удаленно на инстансе что мне эти ресурсы обеспечит.
Но я кажется четко и однозначно процитировал коммент на который я отвчеал. Речь шла о деплойментеГ.michael_vostrikov
28.03.2019 08:22я тот тоже докер разверну удаленно на инстансе что мне эти ресурсы обеспечит
Ну можно и так, а как вы там код редактировать будете? commit+push+pull на каждое изменение?
Речь шла о настройке, которая конкретно в PHPStorm называется "Deployment".
Source
28.03.2019 23:28Приведите конкретный пример, для чего на машине разработчика может не хватить ресурсов? Как правило, она вполне сопоставима с инстансом сервера по мощности. Я могу представить несколько случаев, когда понадобится dev-сервер именно с целью разработки, но это такие редкости, с которыми 99.9% программистов ни разу не пересекались.
И, кстати, сколько у вас таких dev-серверов? По одному на каждого программиста? Или все параллельно правят исходники напрямую на сервере мимо коммитов и молятся, чтобы их правки не переклись? xDmichael_vostrikov
29.03.2019 08:24"2019 год", а люди не знают, что такое площадка для разработки на серверах компании) Я с этим сталкивался как минимум в 3 компаниях, где работал. Так что 99% не соответствует действительности. Обычно делают отдельную папку для разработчика, на нее настраивают поддомен. Коммиты делаются как обычно.
У нас например приложение связано с индексацией больших массивов данных. На сервере для разработки 16 ядер и несколько десятков гигабайт оперативной памяти. Есть несколько сервисов на отдельных хостах во внутренней сети, в коде используются специфичные для Linux вещи. Часть кода на Java, при этом мне не надо держать на своей машине компилятор. Но дело же не только в мощностях. Сервер организации контролируют админы организации — установка пакетов, мониторинг, права доступа, безопасность. Да, есть докер, но приложение делалось задолго до него. Сейчас мы как раз на него переходим.
Source
29.03.2019 10:36У нас например приложение связано с индексацией больших массивов данных.
Ну, ok. И вы на каждый чих запускаете такую индексацию, осознанно замедляя себе цикл обратной связи в сотни раз? Новые фичи прекрасно можно делать с малым массивом данных, а потом проверять на тестовом сервере, куда идёт обычный деплой, и никаких правок руками на сервере.
Я с этим сталкивался как минимум в 3 компаниях, где работал. Так что 99% не соответствует действительности.
То, что кто-то так делает, вовсе не гарантирует, что имеется хоть какая-то необходимость так делать.
Да, есть докер, но приложение делалось задолго до него.
Ну вот по организации работы с кодом оно и осталось где-то на уровне 2007 года, чем и вызывает удивление. Не то, что бы это прям ужасно, но всерьёз обсуждать уже смысла нет. Просто устаревшие практики ещё не отовсюду выпилили.
michael_vostrikov
29.03.2019 11:16И вы на каждый чих запускаете такую индексацию, осознанно замедляя себе цикл обратной связи в сотни раз?
О каком замедлении и какой обратной связи вы говорите? Я редактирую код в PHPStorm, переключаюсь в браузер либо в консоль с ssh, проверяю работу кода. Всё как обычно, только работает это не на моей машине.
Новые фичи прекрасно можно делать с малым массивом данных
Во-первых, это далеко не все нюансы покрывает, особенно касательно производительности, во-вторых, этот локальный массив данных надо поддерживать. В-третьих, зачем мне это все на локальной машине иметь, включая компиляторы для всех языков, в чем необходимость?
вовсе не гарантирует, что имеется хоть какая-то необходимость так делать.
И что вы предлагаете? Переписать? Правильно. И на время переписывания с этим кодом надо как-то работать.
Кроме того, Docker выпущен в 2013 году, и переделывать тогда нагруженное приложение на свежую технологию ради хайпа было бы неудачным решением. То есть не иметь докера на легаси через несколько лет после его выхода, это как раз нормально.
vdem
28.03.2019 00:31+1Сначала коммит, потом пулл, разрешение конфликтов если надо, потом прогон тестов, если проходят — пуш. Или я что-то не так делаю? Какого черта пушить если тесты не прогнаны?
P.S. Впрочем если на сервере настроен автоматический запуск тестов то да, норм.kivsiak
28.03.2019 00:46Вы молодец. Хороший правильный разработчик. Я уверен что у вас привальная машина с полностью настроенным тестовым окружением. Я уверен что вы всегда полностью выполняет весь регламент перед каждым пушем ни разу не пропустив ни одной фазы. Жаль клонировать вас 10 раз современные технологии не позволяют.
tendium
28.03.2019 10:58Ну, если у вас своя feature branch, в которой работаете только вы, то ничего страшного в пуше без прогона тестов нет. Особенно если у вас настроена pipeline на прогон тестов при каждом пуше. У нас я так и сделал, поэтому локально тесты гонять было совсем не обязательно. Единственное, где тесты гонять было крайне желательно, это при мердже feature-ветки в develop и потом при мердже develop в master.
P.S. Пуш даже с неработающими тестами в моем случае хорош еще и тем, что мне, как тимлиду важно видеть прогресс юниора и вовремя направить в нужное русло, чем позволить ему потратить несколько дней на неверное решение. Ну и вообще, в конце рабочего дня неплохо бы показать результаты работы, даже если она еще не завершена.vdem
28.03.2019 11:20До того, как я перешел на фриланс, в конторе где я работал был такой порядок: сначала тесты прогоняются локально, если всё в порядке, изменения отправляются в репозиторий на сервер. На сервере был то ли триггер на пуш в репозиторий, то ли крон-задача, и там тесты прогонялись автоматически. Если какой-то тест фейлился, всем членам команды приходил отчет.
tendium
28.03.2019 10:50Какие сетевые задержки? Вы редактируете в PHPStorm напрямую продакшн?
VolCh
28.03.2019 11:48Сеть сразу подразумевает продакшен? дев-сервера, тест-сервера, стейджы и т. п. не использовали никогда?
tendium
28.03.2019 12:09Использовал. Но никогда не приходило в голову редактировать там файлы напрямую. Всегда использовал push/pull. В одном из проектов при пуше в feature-ветку автоматически создавался dev-проект с кодом из этой ветки.
VolCh
28.03.2019 13:08А мне никогда не приходило в голову использовать пуш-пул для того, чтобы посмотреть промежуточные результаты, проверить гипотезу, сравнить по скорости несколько вариантов и т. п., просто запустить отладчик. Не то, что пуш, а коммиты делаю на логически целостные куски.
krysanoveo
27.03.2019 07:39Нормально будет если замените HDD на SSD
iproger
27.03.2019 07:54Без этого сейчас никуда. Тем более ssd в 2019 уже ставят даже в бюджетные машины.
franzose
27.03.2019 00:48+4Вы за работу получаете деньги. И вряд ли какая-то непреодолимая сила мешает вам накопить на лицензию. Продукт у JetBrains действительно шикарный.
JohnDaniels
27.03.2019 18:11Не в тему, но может вы знаете: как в шикарном продукте JetBrains включить отображение папки node_modules? у меня второй день работа тупо стоит. вопрос на тостере
franzose
28.03.2019 03:54Не поверите, но я тоже натыкался на эту проблему. Однажды добавил эту папку в
Excludedи она пропала из виду. Починилось это, если не ошибаюсь, только с переходом на следующую мажорную версию. У меня сейчас PHPStorm 2018.3.4.
trawl
27.03.2019 06:59Не так уж и дорого. А ещё EAP есть, если денег мало. Ну или ежемесячный сброс триала, если мало не только денег но и совести
sumanai
27.03.2019 19:33-1Использую бесплатный VSCode с открытым исходным кодом, и плагин PHP Intelephense к нему, что делает мою работу не сильно отличающийся от IDE.
А заминусовали так, как будто я в виндовом блокноте предлагаю править.
OnYourLips
26.03.2019 20:43Если мы отходим от Django в сторону Tornado/aiohtpp/Twisted/Flask итд – то там начинается боль, ибо код в них писать гораздо неприятней, чем в Django.
Вам нравится Django и Symfony одновременно, но не нравится Flask? Почему?
Лично из этих трех мне не нравится только Django (из-за его django.db), Flask же значительно ближе к Symfony.
hudson
26.03.2019 20:52Мне кажется даже ближе к Silex или Flex. Обвешиваешь чем нужно, по потребностям, из коробки минимум.
trawl
27.03.2019 07:07Silex — это и
естьбыл микро-Symfony. С июня 2018 Silex полностью прекратил развитие.hudson
27.03.2019 07:42+1Ну да, базовый Flex его заменил. Я про общую идеологию, берем минимум, обвешиваем тем что нужно.
s0lar
27.03.2019 10:29Вы немного путаете. Silex — это был микрофреймворк от создателей Симфони.
А Flex — это плагин, от Симфони, который помогает настраивать приложение на Симфони через composer используя рецепты.
То есть используюя Flex вы намного проще можете расширять свое Симфони приложение. Вы пишите composer require mailer и composer добавляет новый пакет, а Flex автоматически прописывает его везде где нужно в конфигах Симфони.
MSC6502
26.03.2019 21:43Если разработку нужно вести по типизированным «паттернам», то тогда вообще зачем нужны разработчики? Нейросеть -> «разработчик №1» и «разработчик №2». и всё.
BoneFletcher
26.03.2019 23:05У каждого языка есть свои преимущества, на старте проекта нужно очень тщательно взвесить все «за» и «против». Главным преимуществом PHP всегда были скорость и простота разработки, и если раньше, когда каждый писал свой велосипед, вы платились за это качеством кода, то теперь, Symfony/Twig/Doctrine в связке с PhpStorm установили высокий стандарт разработки, что называется, «из коробки». Достаточно набросать базовую структуру проекта, определить стандарты разработки, найти несколько хороших программистов по 100 тыс/мес на удаленке, прособеседовать их по скайпу, организовать рабочий процесс — и через несколько месяцев можно будет сдавать рабочий проект. Это будет намного дешевле и быстрее чем разработка на Java/C#/Python и т.д.
Главный недостаток PHP — на нем можно сделать не все. Он отлично справляется с тем чтобы принять запрос, обработать его, вернуть ответ и «умереть», но если требуется что-то большее, например, непрерывный обмен данными — сразу начинаются проблемы. В других языках таких проблем нет, в том же nodejs можно сделать все что угодно, за все время работы с ним, мы ни разу не столкнулись с тем чтобы не смогли что-то сделать, в то время как с PHP эта проблема всплывает постоянно и приходится решать ее неприятными «костылями». Но и в nodejs есть свои существенные минусы, так что идеального решения не существует и нужно индивидуально подбирать стек технологий под каждый проект.
porn
26.03.2019 23:25если требуется что-то большее, например, непрерывный обмен данными
reactphp.orgBoneFletcher
27.03.2019 01:16Только для совсем простых сервисов, большие проекты на нем делать я бы не рекомендовал. По сути это вообще новый язык на основе PHP, там свои пакеты для работы с файловой системой, сетью, базами данных и т.д. Стандартный набор пакетов не очень большой, а сторонние пакеты оставляют желать лучшего. У нас был проект на reactphp/ratchet, работал стабильно, но работать с ним было очень тяжело, поэтому мы его переписали на nodejs/socket.io
hatman Автор
27.03.2019 03:02В крупных проектах идет что-то типа:
symfony -> rabbitMQ -> node.js (go) -> клиент (ДБ)
т.е. пхп запускает какой-то кусок данных, а все остальное уже идет через очереди, ноду, прослойку итд.
uvelichitel
26.03.2019 23:14я пересел с проектов python/java на проект на php (мне предложили условия от которых было бы глупо отказываться)
java==кровавый_энтерпрайз с оглушительными salary, в гаражных проектах не применяется. Интересно, какие же нужно было предложить условия чтобы сдернуть с тучных пастбищ.zim32
27.03.2019 00:38Может ушел в казино онлайн играй без блокировок только у нас! Там зп как в джава энтерпрайзе.
hatman Автор
27.03.2019 03:241) Рынок ПХП-разработчиков, которые могут в Symfony весьма скромен (отсюда и конкуренция за ручки).
2) Количество энтерпрайз проектов на Symfony увеличивается с каждым годом (люди переписывают свои легаси проекты на пхп на него)
3) Так как это уже действующие проекты, то бизнесу проще поднять планку зп и добавить плюшки, нежели сидеть без разработчиков, либо переписывать все на другие платформы с новыми рисками.
4) Чтобы получать оглушительными salary в Java надо тоже постараться. Там далеко не всем и не везде платят больше 130-140 тысяч. И далеко не всегда эти деньги стоят того, чтобы так работать.
ivorobioff
26.03.2019 23:33-2Я писал все время на php + symfony 2/3, затем пересел на java + spring 5+, ни какой такой боли или вообще не удобства не почувствовал, а скорее на оборот, радость и ощущение свободы. Да, symfony и php не плох, но spring и java намного кручи, и дает такие возможности которые в php не сделать.
TimsTims
27.03.2019 01:23Замените слова php, symfony, java и spring на любые другие слова, и ваша аргументация ничуть не пострадает. «Он не плох, но этот ещё лучше!». А чем плох, чем лучше не понятно.
ivorobioff
27.03.2019 08:24-1Ну я не статью пришел здесь писать. Говорю свое сугубо личное мнение. О том чем пхп хуже или лучше джава есть кучу статей включая эту.
TimsTims
27.03.2019 09:06Ну и мы же в комментариях читаем не статьи, а мнения людей, и очень ждём аргументов. А вы вроде и написали адекватный комментарий, что у вас был большой опыт, но почему что-то лучше — не написали. Выходит, вы зря написали свой комментарий — вроде бы и написали что-то, но ничего не сказали.
ivorobioff
27.03.2019 09:24Где это написано, что комментарии должны обязательно аргументироваться? Я захотел просто и кратко опровергнуть конкретную точку зрения из статьи, где говорится что Spring это система которая вызывает анальную боль, а вот Symfony это бомба.
В своем комментарии я обобщенно описал свое ощущение перехода от одного инструмента к другому. Ощущения не аргументируют. Нужны аргументы читайте статьи.
poxvuibr
27.03.2019 09:32Автор написал, что ему spring не понравился потому что он какой-то сложный и вообще, а ему комментатор ответил, что комментатору спринг сложным не кажется, а кажется намного круче. Уровень аргументации примерно одинаковый. Что не так?
Khaperets
27.03.2019 01:04В каждом языке есть свои плюсы и недостатки, грамотный разработчик под свою задачу найдет нужное решение на необходимом языке. По поводу Symfony: работаю более 5-ти лет с этим фреймворком, и для меня это самый лучший каркас для разработки PHP-приложений. Всегда использую последние версии языка/фреймворка и с выходом Symfony 4 & PHP 7 — просто сказка, приложения получаются лаконичными и очень качественные во многих аспектах.
kuftachev
27.03.2019 01:58-1У меня на PHP реальный опыт только на Yii2, который, к сожалению устарел.
Я вот тоже раньше любил шутки про PHP, пока не посмотрел в сторону Python, который официально принято всячески хвалить. После этого я понял, что PHP — это очень крутой современный язык, а это ещё до PHP 7 было.
Но к Symfony отношусь скептически, когда его смотрел, эта была попытка сделать Spring на PHP, в общем, все грустно как-то.
Сейчас, в связи с постепенным уходом на пенсию Yii2, перешли на Go под новые проекты. Реально довольны, он просто вне конкуренции.
Soo
27.03.2019 07:10в связи с постепенным уходом на пенсию Yii2
А почему это Yii2 собрался на пенсию? Его совсем никто-никто не поддерживает?asd111
27.03.2019 08:07Автор китаец, который написал 99% фреймворка, ушёл из проекта пару лет назад.
olegl84
27.03.2019 12:47И что? Если посмотреть по коммитам, то Yii2 живет. Пока для себя я альтернатив не вижу. Laravel медленнее работает, на Symfony медленее писать.
EvgeniiR
27.03.2019 13:20на Symfony медленее писать.
Статистикой не поделитесь? Сколько я не видел людей которые рассказывают как быстро они на Yii круды пишут, на вопросы почему у них этого не получается на других фреймворках типичный ответ: «Ну я пришел к бизнесу сказал так то так то, я знаю Yii, но не знаю Laravel, поэтому на Yii писать проекты быстрее», а потом идут этот же тезис доказывать остальным.
P.S. я не видел проектов которые с 0 переходят в статус 100% готовности и отутствия необходимости в поддержке после того как разработчик CRUD через gii сгенерировал, а как только придется что-то кастомизировать, поддерживать и дорабатывать, вся скорость улетучивается.
Laravel медленнее работает,
PHP тоже медленее работает. Почему же вы на нём пишете вообще?)
И уверены ли вы что скорость работы вашего приложения действительно упирается во фреймворк, а не в БД, например?olegl84
27.03.2019 13:37Статистикой не поделюсь. Есть только личный опыт, есть проект на Symfony и Yii. На сифони нужно больше кода писать + больше кода в самом фреймфорке(в основном абстракций), то есть дольше разбираться в нюансах работы.
говоря про скорость я имею ввиду все параметры, в том числе и память. а если у меня скажем 30 запросов в секунду, то разница может быть существенная. но ларавел мне не понравился по другим причинам, но под xdebug при отладке на локальной машине разница в скорости заметна. по крайней мере на той машине что была у меня когда я изучал этот вопрос.EvgeniiR
27.03.2019 16:36но ларавел мне не понравился по другим причинам, но под xdebug при отладке на локальной машине разница в скорости заметна. по крайней мере на той машине что была у меня когда я изучал этот вопрос.
Ну то есть даже полноценных бенчмарков не было. Ок.
p.s. 30rps не серьёзно, у вас горлышко будет вовсе не в ЯП если конечно не будете ССЗБ
больше кода в самом фреймфорке(в основном абстракций), то есть дольше разбираться в нюансах работы.)
В моём понимании, абстракция — сокрытие несущественных деталей, и если абстракция мешает вам пользоваться фреймворком, есть два варианта:
1. Вы явно делаете что-то не так.
2. Абстракции некачественные, контракты ломаются. Но тогда хотелось бы от вас примеры таких абстракций
По поводу лапшекода — да, когда у вас проект на пару тыс. строк возможно писать процедурщину забив на разделение ответственностей и coupling будет и быстрее и понятнее, но чуть времени и вы даже не заметите как это всё превратится в трудноподдерживаемое легасиolegl84
27.03.2019 17:27Абстракция и реализация абстракции все же разные вещи. То есть там где у Yii 3-4 класса, то у Symfony задействовано 7-10. И вместо классов интерфейсы, то есть без запуска отладки очень не просто, если вообще возможно найти конкретную реализацию.
Ну я не считал кол-во строк, но проектам которые я делаю скоро по 5-10 лет, и я всегда в Yii с лекостью нахожу и понимаю код который мне надо менять. Другое дело сами изменения. Но тут я не думаю что проблема в Yii или Symfony, тут вопрос статичесой/динамической типизации + покрытия тестами. Моя лично практика показывает что в PHp важшее простота, а не «правильноть». Все эли SOLID созданы для типизированых языков, и там да, проблема будет если код не гибкий, а PHP гибкий by design.
Source
28.03.2019 21:5830rps не серьёзно, у вас горлышко будет вовсе не в ЯП
Это из серии "Снимаю порчу по фотографии, определяю горлышко по кол-ву rps"?
Travelcamnet
27.03.2019 02:51А мне нравится Yii2 )))
FRiMN
27.03.2019 08:29На мой вкус есть сомнительные решения в нем.
olegl84
27.03.2019 12:52Какие?
EvgeniiR
27.03.2019 13:251. Велосипеды, крайне неудобные и некастомизируемые
2. Глобальные переменные
3. Статика
4. Программирование на массивах
5. Ужасные AR модели, которые по сути God-object`ы
6. Меньше ограничений, вызов Yii::$app в html шаблоне — типичное дело. Да, конечно, это проблема скорее программистов, но вышеперечисленное плюс ужасные практики навязанные документацией, в совокупности с тем что половина пользователей используют Yii потому что даже Английский не осилили( и, соответственно, ничего больше не знают ) = низкий уровень разработчиков и ужасные проекты.olegl84
27.03.2019 13:44Что на ваш взгляд лучше?
EvgeniiR
27.03.2019 16:43Фаулера читать лучше всего ) Сразу приходит осознание, что ничего вобщем то нового в этих всяких фреймворках нету.
А так, Symfony, Laravel —стильно, модно, молодежнои по функционалу впереди, и с перечисленными пунктами всё получше. Zend вроде вполне годная штука, но я так и не смотрел его, к сожалению.olegl84
27.03.2019 17:31Когда я читал фулера, я все это знал на своей личной практике.
Lravel под капотом — это упражнения автора в интелектуальном труде, то есть там сделано умно, но когда мне надо быстро разобраться я предпочитаю «просто».
Symfony это всегда не нужный расход ментальной энергии. Возможно проблема в том, что я пишу PHP проекты в одиночку, в команде конечно наверно лучше Symfony, но я бы выбрал .NET Core MVC.EvgeniiR
27.03.2019 20:55Если вы пишите в одиночку и каких-то больших перспектив у проекта нет, вообще без разницы )
olegl84
27.03.2019 17:59-1Ешё на счет Laravel, сейчас это вроде поправили, но когда я его смотрел последний раз там предлагалось валидировать модель в контролере. После Yii это казалось дикостью. А в Symfony вообще нету такого понятия как модель в Yii, где класс имеет встроенную поддержку валидации и отображения. Все это надо прикручивать самому и каждый будет это делать по своему. ну не знаю… Конечно все независимо и разделено, но а надо ли разделение функционала ради разделения, это большой вопрос. На мой взгляд в лучше логически связаные вещи объеденять.
VolCh
27.03.2019 20:08+1В Symfony есть понятие модель с точки зрения MVC и оно означает «модель вашего приложения вне фреймворка». Ну и логически валидация и отображение не должны быть объединены с моделью. Одна и та же может может иметь разные режимы валидации и отображения. Это связь один-ко-многим.
olegl84
27.03.2019 20:16Модель очень редко имеет различные отображения (названия полей и их описаие на человеческом). Даже не часто есть разные схемы валидаций. Но в Yii есть поддержка разных сценариев валидаций из коробки, смену отображения тоже легко изменить.
michael_vostrikov
27.03.2019 20:26+2Сценарии неудобны в поддержке, в чужом коде фиг разберешься. Названия полей лучше делать в классах форм, это как бы тоже модель, но другая, не бизнес-логики. Наследовать ее от AR-модели, как делают в документации, тоже не надо.
Нормальная архитектура в Yii выглядит примерно так. У вас есть форма со списком полей и правилами валидации, есть представление, в которое она передается. В контроллере на POST-запрос вызывается метод сервиса, куда передается провалидированная форма. В сервисе уже находится бизнес-логика, где делаются вычисления, создаются AR-модели, заполняются данными из формы и сохраняются. Сервис это просто отдельный класс, который не наследуется от классов фреймворка.olegl84
27.03.2019 20:35Я вроде не говорил что модель должна быть обязательно AR. Но вообще, да норм решение если проект чуть больше или много разных форм.
VolCh
27.03.2019 20:37Как по мне, то такое решение должно быть по умолчанию и только очень веские причины должны быть для использования «магии» формовалидированнойхранимойсущности.
olegl84
27.03.2019 20:44Вообще я лично всегда выношу бизнес логику в отдельные класссы. Но вот сохранение там бы я не делал, сложнее тестировать.
michael_vostrikov
27.03.2019 21:00А где его делать при использовании ActiveRecord, в контроллере?)
VolCh
27.03.2019 21:03В ActiveRecord можно сделать хорошую мину при плохой игре и запретить смешивать в одних методах логику хранения и логику валидации
michael_vostrikov
27.03.2019 21:20+1В моем описании логика валидации находится отдельно в формах. В сервис с бизнес-логикой передается уже валидная форма. Это позволяет без проблем кидать исключения, если что-то не так.
VolCh
27.03.2019 22:28Я про то, что если даже смешать всё в одном классе по каким-то очень веским причинам, то «бить по рукам» за методы со множественной ответственностью. Ну и, условно, вместо штатного метода validateAndSave вызывать отдельно validate, а затем save, если нет отдельного save, то сначала validate, а потом validateAndSave
michael_vostrikov
28.03.2019 00:15Это все правильно, только у меня вообще validate в AR-моделях нет. Если и есть, то только для проверки заполнения полей с внешними ключами, и то больше как дополнительный контроль. Все validate в классах для приема внешних данных (формах).
VolCh
27.03.2019 20:29Как по мне, то очень часто разные в зависимости от контекста. Например, модель сущности Person имеет поле name. В одном контексте это может быть «имя заявителя», в другом «имя агента», в третьем «имя сотрудника» и т. п. И имя заявителя может быть пустым, а имя сотрудника всегда должно быть полным, а имя агента не доолжно быть пустым, но допускает скоращения.
olegl84
27.03.2019 20:39Да, зависит от масштаба проекта. Но в большестве случаев это не надо. И тут возникает дилема, либо мы унифицируем в сторону более сложного решения и получаем оверхед в простых случаях, или делаем просто, и в сложных случаях применяем альтернативное решение. Исходя из моего лично опыта, в PHP второй вариант предпочтительние, потому что я пишу один. Возможно в команде нужны другие подходы.
VolCh
27.03.2019 21:09Наверное, да, если команда, да ещё из специалистов сильно разной квалификации, то польза дефолтного разделения ответственности куда заметнее. Как минимум, минимизируем вероятности, что вместо разделения ответственности в сложном случае начнётся накручивание костылей на простой.
Пока один пишешь легко держать в голове «это простейшее решение для конкретного кейса, шаг влево-шаг вправо переходим на унифицированное сложное». Если несколько человек, да ещё «мне только чуточку поправить эту фичу для моей задачи», то проблемы практически неизбежны.
olegl84
27.03.2019 18:11раз уже завязалась дисскусия, то разберу ваши пункты:
1. Велосипеды, крайне неудобные и некастомизируемые
Они аргументируют что их велосипеды удобные, хотя по функционалу хуже. И лично я согласен. Тот же логгер проще чем monolog, но и не может выводить в консоль.
2. Глобальные переменные
Какие ещё глобальные переменные. Если имеется ввиду Yii::$app, то это по смыслу константа, а в лобальных константах нету зла.
3. Статика
Не люблю как это реализовано, приходиться самому допиливать, но а как сделать лучше и универсально я не знаю сам. Ведь такая реализация там не спроста, она позволяет легко интегрровать визуальные extensions.
4. Программирование на массивах
обожаю. она из основных причин почему использую Yii. С Yii2support плагином единственное решение которое лаконично и удобно. yml например не поддерживается IDE. у xml поддержка весьма ограниченая. в Laravel с этим лучше, но массивы я люблю больше :)
5. Ужасные AR модели, которые по сути God-object`ы
В Yii есть те же репозитории как в Symfony, подозреваю что вы не владеете информацией в нужном объеме
6. Меньше ограничений, вызов Yii::$app в html шаблоне — типичное дело.
Не вижу особой проблемы, это плохо лишь в том случае, если нам надо будет использовать код в другом, не Yii проекте. Но это очень редкий случай и все равно надо будет инджектить все эти классы. Можно либо реализовать свой Yii:$app или сделать просто Find & Replace.VolCh
27.03.2019 20:10> В Yii есть те же репозитории как в Symfony, подозреваю что вы не владеете информацией в нужном объеме
В Symfony нет репозиториев. Там вообще практически ничего нет, относящегося к управлению постоянными данными.
EvgeniiR
27.03.2019 21:14+1Причем тут репозитории?
Пихать бизнес логику, логику отображения, логику persistence слоя, валидацию в один класс это ужасно.
Могу с уверенностью предположить что у вас не было опыта с другими фреймворками, и не было крупных проектов, поэтому вопрос для вас по сути религиозный. Не хотел переходить на личности, просто ответ на ваши замечания потянет на книгу.
Все же, кратко:
— Read model и Write model могут различаться. Для быстрого и дешёвого проектирования сделать их одинаковыми — норм вариант. С ростом проекта, без рефакторинга, условная сущность Product обрастает просто гигантским количеством логики, зависимостей, и в принципе становится тяжело поддерживаемой. В этот момент возникает вполне резонный вопрос — почему вся эта логика в классе Product? Почему Product должен знать про то как рассчитать цену. Почему Product должен знать каким должно быть описание, почему он вообще знает про SEO и то что нельзя, допустим, располагать в описании тег h4 до h3. Что если бизнес завтра скажет что продукт может быть без цены? Править конструктор в котором 25 аргументов и вызывается он в 150 контроллерах? Что если появляется логика того как должна отображаться цена, и это значение не подходит для операций? Пихать в Product помимо price поле user-friendly-price? Почему это не сущности ProductDescription и Product price? Гуглить CQRS, агрегаты.
Yii::$app — не константа. Это объект через который модно вытащить любую информацию о приложении. Тут уж просто советую гуглить global coupling.
P.s. я пишу на Юи(Легаси), использую его, можно сказать, в полной мере. К сожалению. Постепенно планируем от него отказываться.olegl84
28.03.2019 13:03Увереность вас подводит. 20 лет опыта, C#, Delphi, Java, Php. Самый большой проект — больше миллиона евро бюджета
olegl84
28.03.2019 13:06А Product и не должен это знать. С чего вы это взяли. Смысл того что я написал заключается в том, что контекст использования yii маленький-средний проект. Если у нас команда больше 5 человек, вообще использование PHP под большим вопросом.
olegl84
28.03.2019 13:17То что вы описали в «Все же, кратко:», это вопрос не к фреймворку, а к разработчику. Если у вас сложная логика в одном классе, то это проблема не фреймворка, а архитектора проекта.
youyou2020
27.03.2019 05:25Нормальные ребята изучают другие языки
hatman Автор
27.03.2019 06:48+2Я всегда думал, что:
- цель любого разработчика — решать задачи оптимальным способом
- цель человека — хорошо зарабатывать, вкусно кушать и не дрочить себе мозг без особой необходимости
Причем тут нормальные ребята и языки — я не в курсе.
GrigoryPerepechko
27.03.2019 05:38TL;DR;
Питон — только джанга, остальное фигня
Java — сложно, ну нафиг
PHP — симфони класс, всем рекомендуюhatman Автор
27.03.2019 06:46+1Добавить 4 пунктом: Современные фреймворки на PHP/Python/Java/.NET — одно и то же по сути.
FRiMN
27.03.2019 08:22Плюс документация Django – одна из самых качественных, что я видел
Все стало ясно. Хотя это уже холивар
lonesimba
27.03.2019 08:28-1Фреймворки это, конечно хорошо, но есть
долбодятлылюди (вроде меня) кто работает на чистом PHP, без фреймворков. Вот тут веселье и боль идут. Особенно по ООП. Ну и отсутствию ИДЕ, по функционалу хотя бы похожих на Эклипс\Студию, которые бы не стоили как фотошоп… хотя может я просто не нашел еще его, тогда был бы рад, если бы пальцем ткнули в ссылку.hatman Автор
27.03.2019 08:29А зачем? какая цель всего этого дела?
lonesimba
27.03.2019 08:31Свою CMS делаю, как диплом, плюс буду для себя ее использовать. Не хочу иметь внешние зависимости, по максимуму от них отказываюсь. Хотя некоторые вещи (типа mobile detect или jquery) оставлю, добиться аналогичных функций самостоятельно тут будет сложновато
EvgeniiR
27.03.2019 09:52http://youmightnotneedjquery.com — не благодарите )
Ну а писать проект не используя внешние библиотеки это, конечно, ужас.
lonesimba
27.03.2019 10:16Интересная вещица, спасибо. JQuery я больше "на всякий" написал, поскольку пока только бэкэнд делаю ещё.
Virviil
27.03.2019 10:46В чем смысл делать диплом в 2019 году на jquery? Это же всё-таки не кровавый энтерпрайз, а диплом!
Я понимаю ещё CMS с Wasm на фронте и блокчейном на бэке. Но диплом на PHP с jquery...lonesimba
27.03.2019 10:54Затем, что я его и без диплома делал бы. Да и дипломы у нас в шараге — сплошняком сайты-визитницы. Если под Wasm подразумевался webAssmebly, то это уже выше моего понимания на данный момент, да и узнал я о нем только что от Вас, хотя он выглядит интересно, поизучаю его однажды. А блокчейн на бэке… в ВУЗе, может, диплом и должен впечатлять, но в рядовом колледже, вроде моего, где если хочешь научиться, то гуглишь сам, диплом — просто больше для галочки. Да и с блокчейном у меня не задалось — майнить не вышло нормально, GTX760 не подходящий агрегат, а в рамках предварительного этапа WS мне с тремя товарищами так и не удалось сеть поднять, хотя руководил всем чел, шарящий за это дело.
poxvuibr
27.03.2019 09:45Ну и отсутствию ИДЕ, по функционалу хотя бы похожих на Эклипс\Студию, которые бы не стоили как фотошоп… хотя может я просто не нашел еще его, тогда был бы рад, если бы пальцем ткнули в ссылку.
PhpStorm сейчас стоит 89 долларов за первый год, 71 за второй и с третьего года стоит 51 доллар в год. В рублях это примерно 5800, 4600 и 3300 соответственно. Вот ссылка https://www.jetbrains.com/phpstorm/buy/#edition=personal .
Фотошоп стоит 3400 в месяц, а в год это 40800. Ссылка https://www.adobe.com/ru/creativecloud/plans.html
Легко убедиться, что фотошоп более чем в 10 раз дороже, чем PhpStorm. Так что бегите, покупайте уже сейчас, или дождитесь скидки, в Jet Brains это бывает часто. А если вы студент, то все IDE Jet Brains для вас попросту бесплатны.
lonesimba
27.03.2019 10:11ГБПОУ МГОК в их реестре студенческих организаций точно не состоит — да и студент я только до лета, а там армия. Если бы у них был аналог Visual Studio Community или Life-long лицензия, тогда бы рассматривал, а так, для проекта "для себя" без дохода, покупать даже за такую божескую цену, но каждый год — непозволительная роскошь для меня. Сейчас, по крайней мере, пока я в маке работаю. Хотя там скорее всего буду на .Net буду работать, а пыха уйдёт на второй план
hatman Автор
27.03.2019 10:12Напишите представителям JetBrains на хабре. Мне в свое время годовую лицензию PyCharm подарили для личных проектов на python (хотел пощупать django). Там ребята весьма адекватно идут на встречу.
lonesimba
27.03.2019 10:18Ого, вот это уже необычно для крупной компании. Чтож, возьму на заметку, хотя пример того, как написать правильно, был бы рад увидеть чтоб не наглеть или ещё как-то оплошать.
Fenzales
27.03.2019 13:33ГБПОУ МГОК в их реестре студенческих организаций точно не состоит
Вряд ли у них есть какой-то реестр, просто смотрят наличие актуального студенческого билета.lonesimba
27.03.2019 13:42Не, они требуют почту в домене учреждения.
Пикрелейтед
NickyX3
27.03.2019 14:19Для людей типа вас, любящих «чистый» php есть довольно легкий подрезанный Zend Eclipse PDT, бесплатный. Правда он старый и в нем плохо с поддержкой php7, но в целом ок. И даже кое-какие плагины от нормального Eclipse поддерживаются типа ColorTheme
lonesimba
27.03.2019 14:26Это не тоже самое, что Eclipse IDE for PHP Developers? Просто его пробовал пару раз, но что-то не понравилось, не помню уже что.
NickyX3
27.03.2019 14:41Не совсем, это сборка от самих Zend с их фичами типа поддержки «Project on Remote Server over SFTP/FTP», которая есть в Zend Studio, но в PDT (Community Edition) for Eclipse оно вырезано.
В общем на самом деле это чуток подрезанная старая версия Zend Studio.lonesimba
27.03.2019 14:48А, ну это уже слишком продвинуто для меня. Мне, по факту, только IntelliSense нормальный нужен, а то он теряется с подсказками в VSCode, когда я пишу конструкции типа:
Пример 1<?php public class Lol { private $foo; public function __construct() { $this->foo = new Foo(); } public function Hi() { $this->foo->bar(); //Подсказок по функциям не выведет } }sumanai
27.03.2019 21:16В смысле теряется? На каком этапе у вас отсутствуют подсказки?
lonesimba
27.03.2019 21:31Когда ввожу $this->foo — никаких подсказок порой не возникает. То же самое происходит, если я класс в процедурном файле вызываю. Но опять же — не всегда. Может, конечно, дело в неймспейсах, не знаю.
VolCh
27.03.2019 22:30а нет indexing в статусбаре, когда порой не возникает?
lonesimba
27.03.2019 23:34Перенастроил немного, как в расширении PHP IntelliSense Феликса Бейкера написано, чтоб php.suggest.basic было false. Если раньше выводило таки предложения, просто ни одна из функций членом класса, который в переменную положен, не была, то теперь же он вообще только то, что внутри класса, в котором я пишу выводит. Это если внутри класса. А в процедурном стиле выводит нормально. Если что, у функций видимость public стоит
michael_vostrikov
28.03.2019 00:22Вообще это обозначается через PHPDoc
/** @var Foo */ private $foo;
Если VSCode их не обрабатывает, может какие-то плагины есть.
lonesimba
28.03.2019 00:27так я по примеру выше говорю — что $foo — экземпляр класса Foo, и если обращаться через $this->foo->… то подсказки по содержимому класса нет, если же $foo->..., и происходит это все не в классе, а просто в скрипте, то есть. См. комментарий в ответ на VolCh
michael_vostrikov
28.03.2019 00:33Ключевой момент в моем комментарии — первая строчка в сниппете кода) Это не просто комментарий в коде, он реально парсится редакторами специализированными для PHP.
sumanai
28.03.2019 00:55В VSCode кажется только как документация. По крайней мере код типа
<?php /** * Undocumented function * * @param string $string * @return void */ function test($string) { // } test([]); // тут ошибка: вызов функции с неверным параметром
Не выдаёт каких-либо ошибок, в отличии от кода
<?php function test(string $string) { // } test([]); // тут ошибка: вызов функции с неверным параметром
В PHPShtorm иначе?michael_vostrikov
28.03.2019 01:00Я про автокомплит говорил. Но первый вариант вроде тоже подсвечивается как ошибка.
sumanai
28.03.2019 01:38Занятно. Впрочем VSCode не IDE, походу не всё возможно с редактором. Надо бы ошибку в багтрекер кинуть.
Автокомплит по функциям в VSCode работает, если указать тип переменной или он очевидно выводится. А вот тип переменных, увы, только по самому коду.
sumanai
28.03.2019 00:46А класс Foo есть, файл его открыт или добавлен в рабочий каталог? УМВР
Заголовок спойлера
lonesimba
28.03.2019 01:00Хм, включил снова Intellephense, который у Вас — заработало. Похоже, одной проблемой меньше, за что огромное спасибо и Вам, и всем, кто помогал разобраться, жаль, оценки не могу ставить — ни карма, ни рейтинг не позволяют. Насчет модификатора класса — выплывший кусок опыта с джавой, каюсь, еще одна вещь для правок. П.С.: — для michael_vostrikov — дело не в документировании кода, а в самом отображении, но проблема оказалась в расширении IntelliSense. Хотя если этот сниппет — не просто документация, а реально что-то большее, то с радостью бы почитал хотя бы кратенькую лекцию по ним. Если что, расширение для доков стоит — PHP DocBlocker
sumanai
28.03.2019 01:45Хм, включил снова Intellephense, который у Вас — заработало
Бывает. У меня тоже более популярное периодически отваливалось, забывая комментарии даже для встроенных функций. Кажется даже конфликтовал с другим расширением.
Хотя если этот сниппет — не просто документация, а реально что-то большее, то с радостью бы почитал хотя бы кратенькую лекцию по ним.
PHPDoc помогает там, где не справляется сам PHP. Например, можно указать класс переменной, если он не выводится напрямую, как это бывает в простых случаях. Или тип глобальной переменной. PHP DocBlocker помогает автоматом генерировать PHPDoc комментарии по /**, больше ничего.
VolCh
28.03.2019 07:31Некоторые построители AST и подобных вещей («парсеры») для PHP воспринимают аннотации как часть языка, соответственно очень сильно влияя на автозаполнение.
franzose
28.03.2019 04:39Можно еще курсы на Степике (stepik.org) проходить и получать бесплатную лицензию. Не помню только срок её действия.
lonesimba
27.03.2019 17:10Эхъ, вот она, суть современного дева — люди, отказавшиеся от фреймворков и не скрывающие этого, ловят минусы и непонимание. Хоть вообще не пиши ничего, чтоб не закидали. И ладно хоть бы объясняли, может реально причина серьезный повод что-то поменять.
vlreshet
27.03.2019 17:20+1А что тут объяснять? Практически для любого проекта понадобится как минимум написать такие базовые вещи как роутинг, робота с БД, система шаблонов (views). Писать их самому, вместо использования фреймворка — это строить велосипед, с заведомо худшим качеством, и чаще всего без документации. А ведь это только три базовые вещи, а фреймворки покрывают просто огромную кучу всего. В итоге — если у человека есть возможность использовать фреймфорк, но он этого не делает, то в 99% это плохой специалист который будет писать код который сможет легко поддерживать только он сам (да и то не факт).
EvgeniiR
27.03.2019 21:30У человека явно просто нет опыта, это пройдет очень скоро, с развитием проекта. Пока он не видит в этом проблем, пытаясь как помочь мы либо:
— Напоремся на механизм психологической защиты
— Нагрузим его какими-то терминами которые он пока не поймет
Самай адекватный совет тут — набираться опыта и читать камни. Да, хороший ментор в виде преподавателя или начальника ему очень поможет, но не проходимец с хабраlonesimba
28.03.2019 00:09Но разве поиск каких-то новых путей решения проблемы или просто нарабатывание опыта не проще производить, не пользуясь конструкторами? А то читал где-то, что верстку ту же лучше начинать в обычном блокноте, чтоб не привыкать сходу к красивостям и удобностям типа Emmet и подсветки синтаксиса, и уметь искать проблемы самостоятельно. Или такой подход не правильный?
vdem
28.03.2019 00:25Про себя могу сказать, что пользуюсь редактором Midnight Commander'а (из вкусностей только подсветка синтаксиса). Не люблю подсказки, вдруг выпрыгивающие когда я код набираю, да и запоминается всё лучше гораздо. Понятно, иногда приходится лезть в документацию или гугл, если забыл аргументы какой-то функции. И вообще, это заодно и удобный файловый менеджер — не надо никуда переключаться и водить мышкой. Но я так, фрилансер, а вот в конторах по-любому заставят на IDE перебраться. Кстати, на Upwork когда я на почасовых проектах работаю, ни один заказчик еще не делал замечания за то, что не использую IDE, хотя же видят скриншоты. Это моё ИМХО, мне просто так удобней.
tendium
28.03.2019 00:33Вы где такие конторы видели, где заставляют пользоваться конкретным IDE?
Впрочем, вот какой прикол: рост условного юниора из моей команды до условного мидла как-то подозрительно совпал с переходом с Sublime на PHPStorm. Ничего не утверждаю, но совпадение прям заметно…vdem
28.03.2019 00:50Я не говорил про конкретный IDE, а вообще про IDE. Как бы он повышает производительность труда, не приходится лазить в гугл и в файлы проекта лишний раз. А вообще хз как оно, я уже десяток лет на фрилансе и в офисы больше — ни ногой :) Кстати, думаю такие конторы вполне существуют, где приходится пользоваться принятым в конторе/коллективе набором софта.
VolCh
28.03.2019 07:35В Киеве точно имеются. «Заставляют пользоваться» может не то слово, но должно быть у команды одинаково настроенное окружение с конкретной IDE. При разработке можешь хоть CLI (не TUI) редакторами пользоваться, но если тебе нужна помощь или просто код показать, то будь добр открой «нашу IDE»
franzose
28.03.2019 04:42А то читал где-то, что верстку ту же лучше начинать в обычном блокноте, чтоб не привыкать сходу к красивостям и удобностям типа Emmet и подсветки синтаксиса, и уметь искать проблемы самостоятельно. Или такой подход не правильный?
ИМХО, это полный бред и самоограничение ради самоограничения.
Compolomus
27.03.2019 10:26Странно что автор после первого zf не перешёл на второй или третий, zf тоже всегда толкал доктрину. Конфиги после zf крутить уже не такая проблема. Дока конечно не самая хорошая, но материалы есть.
Симфония не самый простой фв, но и не самый плохой. Есть хорошие фв, но менее популярные из за высокого порога вхождения. Тот же фалькон. Ну и как мне кажется все идёт к midleware
zend-expressive возможно подтянется
lega
27.03.2019 11:58Если мы отходим от Django в сторону Tornado/aiohtpp/Twisted/Flask итд – то там начинается боль, ибо код в них писать гораздо неприятней, чем в Django.
Странно, наоборот, если почитать питон комъюнити, то приходишь к мнению, что джанго — это пережиток прошлого, неповороливый фреймворк для узкого типа сайтов, от которого отворачиваются бывалые разрабочики.
то там начинается боль
У кого-то боль, а у кого-то начианется свобода…
JamesJGoodwin
27.03.2019 12:12прекрасен и продуктивен
синхронный язык с блокирующим I/Omichael_vostrikov
27.03.2019 20:32Для каких задач вам нужен неблокирующий IO?
VolCh
27.03.2019 20:35Например, для написания websocket-сервера он очень хорош.
michael_vostrikov
27.03.2019 20:41На PHP можно делать вебсокеты, я делал, ReactPHP кажется использовал.
VolCh
27.03.2019 21:10ReactPHP базируется на/активно использует/сделан для (не знаю как точнее) для неблокирующего IO
michael_vostrikov
27.03.2019 21:29Ну так с исходным комментарием этой ветки это не сходится. Ну да, в языке нет поддержки, но либы же есть.
andreymal
27.03.2019 21:04Например, для любых? Я буквально на днях завалил один php-сайт, тупо отправив несколько десятков связанных с IO запросов (не буду говорить каких и куда конкретно, чтоб школохацкеров не приманивать), потому что все php-fpm воркеры взялись за IO, а свободные тупо кончились.
Ну и из очевидного вебсокеты, разумеется, тоже. А также long polling и x-mixed-replace, если «классику» вспоминать.
andreymal
27.03.2019 21:33Хотя, справедливости ради, это относится ко всему синхронному с небезлимитным числом воркеров, к Django в том числе
michael_vostrikov
27.03.2019 21:36А в других языках свободных воркеров достаточно? Как я понимаю, это не проблема языка, а проблема настройки сервера.
Вебсокеты на PHP тоже можно делать. С остальным я не сталкивался, возможно там у PHP есть недостатки.andreymal
27.03.2019 21:56Настройкой сервера можно лишь увеличить число воркеров до некоторого предела (оперативка не бесконечная всё-таки) и несколько облегчить проблему, но принципиально проблему это не решит.
Про вебсокеты в php вам уже сказали, что они как раз асинхронные и неблокирующие. Тем не менее, мейнстрим (тот же вордпресс, например) всё ещё синхронный.
Ну да, в языке нет поддержки, но либы же есть.
Либы это неудобное вкостыливание сбоку с callback hell'ом, для хорошей асинхронщины нужен async/await, ну или горутины :)
molchanoviv
27.03.2019 22:33Кстати в пхп даже есть корутины которые можно в асинхронном режиме гонять прямо из веб реквеста не поднимая отдельного reactphp сервера и не ставя swoole. Правда сделаны они пока через генераторы, что как по мне немного криво. В восьмерке обещают впилить libuv и сделать io неблокирующим, тогда и появится нормальная асинхронщина.
З.Ы. а то, что библиотеки это вкостыливание это ты зря. В том-же котлине корутины это тоже библиотека, но лучшей реализации корутин я не видел.andreymal
27.03.2019 22:53в пхп даже есть корутины
Это хорошо, но тогда странно, что гугл по поводу вебсокетов предложил мне пачку библиотек именно с callback hell'ом
сделаны они пока через генераторы
Ну в Python 3.3 корутины и асинхронщина тоже через генераторы, но вроде бы неплохо получилось, лично мне нравится
В том-же котлине
Как я понял из документации, там всё же есть соответствующая фича самого языка, некие «suspending functions», поверх которых запилить удобную асинхронщину уже не так трудно
Фичи php это хорошо, осталось только дождаться, чтобы они до мейнстрима наконец доехали)
sumanai
28.03.2019 00:58Правда сделаны они пока через генераторы, что как по мне немного криво.
Можно пример кода?molchanoviv
28.03.2019 11:02+1Конечно можно. Я для этого использую библиотеку recoil. Так-же есть статья от nikic-а о том как это работает.
class MyClass { private function foo(): ?\Generator { // код не использующий IO yield; } private function bar(): ?\Generator { // код не использующий IO yield; } private function baz(): void { // запуск таск менеджера Recoil. Не путать с ReactPHP. Стартовать его нужно лишь раз, там где нужно использовать асинхронность. можно конечно и во фронт-контроллере стартовать если нужно использовать асинхронность во всем приложении, но пока не сделают IO неблокирующим в этом будет мало смысла. ReactKernel::start( function () { yield $this->foo(); // запуск одной функции в асинхронном режиме yield [ // запуск нескольких функций параллельно $this->foo(), $this->bar(), ]; } ); } }
rdifb0
28.03.2019 01:05I/O легко становится неблокирующим с
stream_set_blocking(). А синхронность в некоторых случаях можно заменить кооперативной многозадачностью через генераторы.
transcengopher
27.03.2019 16:34Непонятно вот это:
Auto-wiring Symfony – даже работает очевидней, чем DI в Spring
Что такого неочевидного в DI Spring'а, который фигачит всего по двум параметрам — имени компонента и его типу (если имени не указано)?
С симфонией я не знаком, зато знаком со Spring, и проблемы с тамошним DI не встречал вообще ни разу (все проблемы на поверку оказались проблемами с AOP).VolCh
27.03.2019 20:14Не помню Spring (лет 10 прошло), но в Symfony достаточно просто в сигнатуре метода контроллера или другого сервиса указать что-то вроде (UserRepository $repo, Request $request) и больше никакой конфигурации.
transcengopher
28.03.2019 17:11Ну да, а в Spring нужно будет метод пометить как
@Autowired. Конфигурации тут прямо жуть как много и неочевидно.
Но то, что вы описываете, когда метод вызывается с параметрами из контекста, спрингом поддерживается только там, где спринг ваши методы вызывает сам, а он этого практически не делает там, где в основном применяется. Вот в методах ответа на rpc-call — делает, и там иногда так можно объявить. В AOP — тоже делает, но там контекст очень маленький, и всего мира так не получить.
Если же метод вызывает ваш код, и компоненту будет нужен объект из DI — придётся либо напрячь вызывающий код, либо объявить зависимость всего компонента, через аннотацию на его поле. Потому что вы не можете вызвать метод в Java и передать только часть параметров, чтобы фреймворк «дописал» в конец списка ещё что-то «недостающее» — это в Java называется oveloading, и через Spring решается опять же инъекцией в поле. В сухом остатке получается, что Spring сложный потому что нужно в объекте поле объявить? Странная логика, как по мне.
Yo1
27.03.2019 17:01с высоты 15+ лет опыта и даже опыта с php+pl/sql прожектов, в изучении пхп нет особого смысла. даже совсем пых-пых сайтику когда-нибудь понадобиться что-то из ML или задеплоить в сервислес амазон. проще один раз вложиться и выучить что-то серьезное, чем распыляться на несколько технологий лишь потому, что там проще вход. та же жава со spring boot думаю уже на порядок меньше конфигурации потребует, чем старичок Symfony. у spring boot в том и идея, что уже все сконфигурено по дефолту и готово подняться.
ну и по деньгам — учить пхп просто не выгодно.olegl84
27.03.2019 18:30А что мешает задеплоить PHP на амазон и прикрутить ML?
И если вы такой крутой с 15+ опыта, то заявление «учить» PHP странно выглядит, там не понятно что учить. Профи за 3 месяца осилит.Yo1
27.03.2019 20:23самый модный из серверлес (AWS Lambda) пхп нативно не супортит, самый модный из ML — гуло тензорфлоу нативного пхп интерфейса не имеет. наверно через какие-то враперы можно заколхозить, но придется изучать и тот язык и этот и костыли-сишные экстеншены которые кто-то в свободное время колхозил под php-tensorflow.
я потому и профи, что знаю, в том числе и какая хрень за каждой «простой на вход» технологией кроется. сам уже с тем самым пхп уже выплачивал, за выход из той простоты. платил за zend encoder, рисовал генератор ёкселя через опу к джаве. вход в пхп был простой, но еще 10 лет назад даже xls в пхп сгенерить было нечемolegl84
27.03.2019 20:28Ну то что PHP НЕ лучший вариант для это задачи это ясно. Но например если я знаю только PHP и нету времени на изучение нового, то на AWS Lambda вроде можно запустить PHP и биндинги есть для tensorflow от разработчика PHP.
Yo1
27.03.2019 21:48вроде есть. вроде можно. но когда ты в это полезешь выясниться что биндинги на какую-то пре-альфа версию. что у пхп объект занимает много больше, тебе нужна память под трейнинг сет и во внешнем модуле и в пхп массиве. что через эту опу только ты и два индонизийца тестировали и затратишь много, много более 3х месяцев на то самое «осилить».
вот и выходит, что «простой вход» очень быстро превращается в ректологию, причем даже на самых хайповых темах.oxidmod
28.03.2019 12:25aws.amazon.com/blogs/apn/aws-lambda-custom-runtime-for-php-a-practical-example
По поводу ML, а в чем собственно проблема использовать подходящий под задачу язык?Yo1
28.03.2019 13:25да не проблема. я к тому что опыт показывает, что разумней сразу вложиться в серьезную технологию типа java, а не клевать на быстрый вход. быстрый вход — обманка, которая очень быстро приводит к секасу. типа того что по вашей ссылке. нет смысла на это тратить время.
oxidmod
28.03.2019 14:34Какой секас по ссылке? лямбда нативно поддерживает пхп от недавнего времени
Yo1
28.03.2019 17:36тот что по ссылке, с компиляцией пых-пых из исходников и подготовкой custom runtime
Before we get started, we should take a moment to consider how native language support on Lambda behaves and how the custom runtime API differs.
…
Since there’s no native support for PHP in Lambda, we’ll need to provide the PHP binary for Lambda to use so that we acn execute our custom runtime code.
перевод нужен?
michael_vostrikov
27.03.2019 20:29В PHP можно генерировать специальный XML, который Экселем неплохо открывается.
vdem
27.03.2019 20:56Как раз ~10 лет назад я для какого-то бельгийца переводил из Perl пакет Write_Excel, или как там он назывался, на PHP, вместе с тестами :)
P.S. Но вроде PHPExcel тогда уже был, это я гораздо позже узнал, правда наверное в зачаточном состоянии.
VolCh
27.03.2019 20:24Symfony 4+ совсем не старичок, и как раз по конфигурации прежде всего. По сравнению что было в 2 (вы же знаете, что symfony 1.х и Symfony 2+ — это совершенно разные проекты?) — практически несравнимые вещи.
kivsiak
28.03.2019 02:26+2Я прекрасно понимаю автора вот есть ситуации когда сложно отказаться. Но в чем смысл статьи в 2019? Пхп наконец то стал языком на котором можно писать?
Я честно без сарказма рад за пхп. Это тот язык на котором я заработал и первый рубль и первый доллар. Я был его большим фантом еще во времена 4.x и был сильно рад переходу на 5.3 ( я думаю тут еще есть люди что помнят этот переход и все те позитивные эмоции)
И тут я вспоминаю свой 2009 год. Когда мне пришлось столкнуться с java c питоном… с ruby. Работа потребовала выбраться из уютного мирка. И тут я понял что движуха не в пхп. Зенд симфони (2009 год напомню) прут все с рельс с джанги с спринга. Чувствуешь себя вечно догоняющим. Где-то появляются новые технологии. Потом смена специализации на java + python. И тогда статьи на пхп можно писать демонов, мы почти побороли утечки, наши фреймворки ниче так, почти рельсы, почти джанга, почти спринг… Зато у нас низкий порог входа.
Прошли годы… Запустить проект на джанге, на рельсах, на спринге может и мартышка. Появилась нода. Появился го. Наработаны и внедрены практики. Можно делать сервлесс (тот еще базворд) инфраструктуру. Лямбды, облака, Async, Движуха.
И вот 26.03.2019 в статье я читаю что мы наконец-то имеем шаблоны не хуже чем в джанге orm уровня рельс и тайпхинтинг. Добро пожаловать обратно на пхп?
И вопрос кто аудитория этого поста? Те кто серьезно завяз на пхп? Ну voloch на пхп даст фору любому джависту с пхп он никуда не слезет.
Те кто давно на java? Их язык уже давно ушел вперед со времен java 6. Если им станет скучно у них есть java 12, есть котлин, есть скала.
Рубисты давно свали на ноду и го. А те кто остались посмотрели и сказали о прикольно эти нас наконец догнали.
Питонисты хмыкнули чекнулись кружками с явистами и пошли дальше писать на 3 питоне.
Причем я говорю не только о языке. Все альтернативы имеют зрелую и в тоже время развивающийся экосистему. Я очень рад что композер перестал тормозить. Но это эти проблемы уже решены лет 10 как. В других языках.
И что я вижу. Опять поддержка легаси… дешевые программисты… Все ровно те же аргументы что я слышу 10 лет.
Вот только за последние 2 года мне приходится не сколько писать сколько руководить.И вижу, что есть адекватные java инженеры за меняемые деньги, Стало до фига джангистов разного уровня. Прототип мне проще взять ребят что пишут на Nodejs и React. Старые асскалы насильники что на go пишут. Молодые джуны но уже понимающие практики. Пхп? Да есть адекватные сеньеры — пхп их сознательный выбор они на любом языке будут писать хорошо.
Фреймворки либы на любой вкус и язык.
И вот к чему вся телега выше.
2005 год релиз php4.4 альтернатив в своей нише нет кроме перла.
2019 год — разнообразие альтернатив под конкретную специализацию. пхп опять в роли догоняющего.
Почему я должен начать писать свой проект на PHP?hatman Автор
28.03.2019 04:45Почему я должен начать писать свой проект на PHP? — без понятия, я свои личные проекты тоже пишу не на пхп, пишу их на джанго.
Почему работаю на пхп — это хорошая продуктовая компания, которая платит выше рынка, и на работе мне не трахают мозги. Разве надо что-то еще?
Что касается владельцев бизнеса, то я уже объяснял, что компании на ПХП — это достаточно зрелые компании, которым дешевле всего переводить свои легаси проекты на ПХП — на современный симфони, нежели как-то перелазить на другую технологию. И опять же, на что ты будешь переписывать:
java/.net? — добро пожаловать в мир конкуренции за прогеров с банками, нефтяными компаниями, телекомом итд.
Ruby/Python — ну руби потерял свою популярность в РФ и «умер», какова вероятность, что Python не последует за ним.
node.js/go — ну это совсем для других задач.
В итоге, бизнес выбирает ПХП
apapacy
Хотя я не разрабатываю реальные проекты на на Symfony, но могу сказать что Doctrine ORM имеет по крайней мере две фичи которые не повторила ни одна crm
1) Автогенерация миграций, которые потом можно дополнятть своим кодом. При этом текущее состояние программного кода сравнивается с текущим состоянием базы данных. Аналоги есть. Но там такие варианты
— автомиграции в стиле sync nodejs-siquelize — когда не управляешь ничем и orm частично изменяет на лету структуру базы данных
— автомиграции в стиле go-kallax — когда генерируется некоторая промежуточная структура данных в которой делается слепок текущего состояния струкуры базы данных. И миграция генерируется не от текущего состояния базы данных а от этого состояния снимка базы данных, которое может и не на все 100% соответствовать текущей структуре базы данных
— автомиграцми в стиле liquibase-hibernate — когда сравнивается текущее состояние базы даных и текущая схема данных, но генерируется не программный код а документ xml. То есть миграция изменит схему но нет возможности кастомизировать миграцию свое йлоггико миграции
2) локализованные текстовые поля. Для локализации достаточно задать в схеме аннотацию что поле переводимое и все. Дальше модно работать как юудто бы с плоской таблицей но поле будет переведено на нужную локаль.
Некоторое время назад недоставало инструментов для быстрого создания админок (типа Django) но на сегодняшний день они уже есть.
Magister7
Django же. Правда сравнивается текущее состояние программного кода с прошлым состоянием его же, но минусом это не считаю, т.к. с чего бы прошлому состоянию не соответствовать базе?
andreymal
Миграция должна генерироваться от состояния предыдущей выполненной миграции, как в Django. А это состояние должно полностью соответствовать состоянию базы данных: если не соответствует, то это какой-то неконтролируемый трындец, работать с которым опасно
В той же Django из коробки действительно нет, но нетрудно написать вручную (я для одного своего проекта недавно писал как раз) (можно по желанию опубликовать реализацию на PyPI, чтобы всем остальным не приходилось вручную писать — возможно, кто-то уже даже опубликовал, я не проверял)
Perlovich
Ну это вы зря. В нашей компании, например, для Java разрабатывают CUBA.platform. К ней есть Studio в виде плагина к Intellij IDEA, которая и миграции позволяет генерировать/менять, и поля локализировать.
Если что, не реклама. Я к созданию/поддержке фреймворка отношения не имею. Работаю в другом бизнес-подразделении.
vidyakinsergey
CUBA это жалкая попытка портировать 1С на яву ))
apapacy
CUBA.platform насколько я понимаю это уже не бесплатно хотя возможно и хорошо. Что касается платных продуктов (или же закрытых внутрикорпоративных продуктов например то что использует у себя внутри Google или Facebook и никому не продает за деньги) то я вполне допускаю что могут быть и более продвинутые решения.
Perlovich
Нет, на самом деле, совершенно наоборот. Многое из того, что раньше было платно, стало бесплатным. Значительная часть функционала студии сейчас бесплатна, независимо от величины проекта. Также сделали бесплатным многие плагины (например, гугл-карты, чарты) и выложили их source code на гитхаб.
A1ien
На счёт миграций, EntityFramework же, умеет все и по-всякому...
FreeBa
Тссс, тут люди радуются возможности указывать тип возвращаемого значения, а вы им про всякую строготипизируемую ересь вещаете…
hatman Автор
Кстати, EntityFramework Core уже взял все фичи от оригинального EntityFramework или еще есть пропасть по функционалу?
questor
Ну, для средней работы всё давно на месте, но бывают фичи, которые были и до сих пор не перенесены. Помнится, я ждал выхода ef core 2.? ради какой-то штуки, которая понадобилась и как назло не было. Ни в 2.1 не было, ни в 2.2, поэтому так и остался воркэраунд.
А вообще — сильно зависит от того, что вам нужно в вашем проекте. Почитайте например здесь changelog docs.microsoft.com/ru-ru/ef/core/what-is-new/ef-core-2.2 и лог предыдущих версий.
impwx
Некоторые редкоиспользуемые фичи все еще отсутствуют — например, связь «много ко многим» без промежуточной таблицы. В целом же EF Core 2.2 вполне «взрослый» и готовый к продакшену.
olegchir
> не программный код а документ xml
1) миграция производится не для 1 конкретной базы данных, а для всех-всех-всех. Синтаксис SQL может и будет отличаться. Из XML генерится разный SQL в зависимости от ситуации.
2) свой SQL в Liquibase писать можно. Хотя это боль и унижение, потому что смотри пункт 1 — оно будет непортируемо между разными БД
poxvuibr
Свой sql писать придётся, потому что понадобятся фичи, специфичные для используемой СУБД.
apapacy
В doctrine генерится не sql а php поэтому кастомизируктся миграция средствами orm и поэтому переносимая между базами данных