Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 64
уже 5.6 а реальный мир на 5.3, 5.4
С выходом 5.6 поддержка 5.3 прекращается, нормальные хостинги на 5.4 уж должны переползти. Хотя, я не считаю это проблемой. Тем, кто видит преимущества новых версий вряд ли будет сидеть на шаред-хостинге.
Согласен, что переползли или переползут, но этот процесс долгое занимает время. Например в нашей конторе часть огромного корпоративного приложения написано на рнр 5.4 и вот сразу так резко перейти на 5.5 или 5.6 мы не может, т.к. все переходы всегда бажат, как не тестируй. В итоге страдает и клиент и бизнес.
Вы преувеличивете сложность перехода. Все гораздо проше, но тестировать, да, прийдется.
знакомо
странно, тут зело поможет CI и тесты
если у вас этого нет — тогда очень печально
странно, тут зело поможет CI и тесты
если у вас этого нет — тогда очень печально
С учащением версий PHP переезжать стало на порядок легче.
Если при переезде с 4 на 5 и с 5.2 на 5.3 приходилось слишком много перелопачивать, то переезд например с 5.3 на 5.5 требует каких-то микроскопических правок, и то в редких кейсах.
С другой стороны ждем 7-й PHP, думаю там поправить придется больше, так как возможно будет потеря обратной совместимости в части синтаксиса
Если при переезде с 4 на 5 и с 5.2 на 5.3 приходилось слишком много перелопачивать, то переезд например с 5.3 на 5.5 требует каких-то микроскопических правок, и то в редких кейсах.
С другой стороны ждем 7-й PHP, думаю там поправить придется больше, так как возможно будет потеря обратной совместимости в части синтаксиса
На самом деле переезд с 5.3 на 5.5 для некоторых проектов может быть нетривиальным развлечением, особенно если эти проекты изначально были написаны на 5.2. Банальный пример — использование расширения php_mysql. Если в приложении много работы с БД и она осуществляется через это расширение, то я могу только посочувствовать разработчикам. Скорее всего, им придется переписывать весь слой работы с БД.
Да, мы все знаем, что php_mysql — это не по феншую, но во времена 5.2 использование этого расширения не было чем-то необычным.
Да, мы все знаем, что php_mysql — это не по феншую, но во времена 5.2 использование этого расширения не было чем-то необычным.
в 99% случаев используется обертка хоть какая-нибудь. Так что поменять на mysqli/pdo особо труда не должно составить.
Я понимаю, что мой пример не показатель, но как говорится «кто о чем, а вшивый о бане». В Битрикс только в 2014 году реализовали поддержку mysqli. Оберткой для смены там не пахнет.И я боюсь они не одиноки.
Подтверждаю. Не испытываю ни малейшей радости от этого, но даже сейчас продолжаю встречать проекты, где используется php_mysql без каких-либо оберток, а ошибки E_DEPRECATED просто блокируются в index.php. Причем сами проекты неплохие, просто довольно старые.
Да и сам имею опыт рефакторинга, когда было нужно на довольно крупном проекте перевести работу с php_mysql на pdo. Вообще, я, как и большинство программистов, испытываю положительные эмоции от процесса рефакторинга (когда код становится красивее, чище, работает быстрее и проч). Но перевод с mysql на pdo — это удовольствие для извращенцев.
Да и сам имею опыт рефакторинга, когда было нужно на довольно крупном проекте перевести работу с php_mysql на pdo. Вообще, я, как и большинство программистов, испытываю положительные эмоции от процесса рефакторинга (когда код становится красивее, чище, работает быстрее и проч). Но перевод с mysql на pdo — это удовольствие для извращенцев.
Но перевод с mysql на pdo — это удовольствие для извращенцев.
Если честно, не вижу в этом ничего особо извращенного. Скорее скучно, много методичной работы. Хотя часть можно автоматизировать. А так как по мне не сильно отличается от любых изменений в старых проектах. Если времени выделяют на это дело достаточно, то можно еще и тестами покрывать по пути (интеграционными хотя бы).
Может мне кто-то объяснит, зачем работающий продукт переводить на более новую версию языка? Всегда читаю и умиляюсь. Одно дело, когда он на этапе активной разработки, но тогда о скором релизе новой версии разработчики должны были быть в курсе и писать код в соответствии с этим, а если у Вас уже давно идет поддержка проекта, то зачем?
зачем работающий продукт переводить на более новую версию языка?Вот что первое на ум приходит:
* версия перестает получать поддержку, в том числе security-патчи
* увеличение производительности в свежих версиях. Если проекты крупные и/или их много — выгода может быть очевидна
* уменьшение количества поддерживаемых версий ПО в организации (новые проекты мы ведь пилим на новых версиях ПО, верно?)
версия перестает получать поддержку, в том числе security-патчи
Сколько людей их ставят, когда они выходят? Ну и еще… Большая часть проектов имеет массу уязвимостей в коде, а вы аж на уровень языка полезли…
увеличение производительности в свежих версиях. Если проекты крупные и/или их много — выгода может быть очевидна
Производительность в веб чаще всего упирается вовсе не в язык программирования, а в БД и архитектуру.
уменьшение количества поддерживаемых версий ПО в организации (новые проекты мы ведь пилим на новых версиях ПО, верно?)
Это единственный плюс, но в крупных организациях, как правило важнее все таки стабильность и надежность, чем количество версий ПО.
Я не эксперт, но таки работаю в крупной организации и мы намеряно фиксируем версию PHP, что бы невзначай не обновиться. Коллеги из других организаций, как правило делают так же. А если говорить о всяких веб-студиях, то потребность в обновлении вообще сомнительная идея.
Сколько людей их ставят, когда они выходят?
Может и не так много, и тем более мое сообщение не про крупные фирмы, но по своим знакомым заметил интересный факт: до апреля 2014 многие игнорировали security-обновления, иногда посматривая Changelog'и и комментируя вопрос «Ты не обновлялся?» что мол эта вот уязвимость «лабораторная», эта — бессмысленна в плане использования, и в таком духе (при этом большинство таких комментарияев основывались на беглых вычитках из статей).
После Heartbleed с бешеной легкостью экплуатации и увиденного своими глазами результата на своих же серверах, за security-патчами стали следить и стараться если не каждый раз, то хотя бы периодически обновляться почти все.
Windows XP пользуетесь, небось?
Оу, а вы знаете, что гос. учреждения ей и пользуются? А знаете почему? Примерные причины я описал выше.
На хабре принято воспринимать в штыки комменты и минусовать. Я получил 10 минусов и пока только одно дельное предложение, с которым я неполность согласен.
Ваш же тезис применим для частного случая использования, а не для использования в рамках организации. Я все-таки надеюсь, что тут собрались не только те, кто штампует сайты-визитки.
Если отвечать более развернуто и объяснять мой первый пост:
Преимущества от обновления версии PHP в крупном проекте чаще всего не стоят средств, затраченных на это обновления. Да и в сухом остатке эти преимущества весьма сомнительны. Давайте так: у вас есть стальной молоток, он вполне себе справляется с задачей забивания гвоздей в деревенную стену. И тут компания-производитель выпустила молоток из более прочной стали, вы купите себе новый молоток, при условии, что старый полностью справляется со своими задачами??? Не кажется, что здесь несвежими абсурдами немного попахивает?
Представил, как кике-нибудь Гос.Закупки сегодня срочно побежали обновлять ВСЕ свои сервисы на новую версию PHP.
На хабре принято воспринимать в штыки комменты и минусовать. Я получил 10 минусов и пока только одно дельное предложение, с которым я неполность согласен.
Ваш же тезис применим для частного случая использования, а не для использования в рамках организации. Я все-таки надеюсь, что тут собрались не только те, кто штампует сайты-визитки.
Если отвечать более развернуто и объяснять мой первый пост:
Преимущества от обновления версии PHP в крупном проекте чаще всего не стоят средств, затраченных на это обновления. Да и в сухом остатке эти преимущества весьма сомнительны. Давайте так: у вас есть стальной молоток, он вполне себе справляется с задачей забивания гвоздей в деревенную стену. И тут компания-производитель выпустила молоток из более прочной стали, вы купите себе новый молоток, при условии, что старый полностью справляется со своими задачами??? Не кажется, что здесь несвежими абсурдами немного попахивает?
Представил, как кике-нибудь Гос.Закупки сегодня срочно побежали обновлять ВСЕ свои сервисы на новую версию PHP.
Если проект написали и забыли, то да, возможно. Если проект находится на суппорте, если к проекту каждый месяц или чаще приходит какой чендж-реквест, то это все та же разработка, просто более чувствительная к факапам. Так же есть такая забавная штука как рефакторинг. То есть за время жизни проекта большая часть оного бывает переписывается до неузнаваемости. И согласитесь, не использовать новые вкусности только потому что вам лень обновляться это как-то глупо. Добавить еще один прогон тестов на новой версии PHP на CI сервере пробле ни у кого не составит.
Правда все это имеет смысл только если проект покрыт тестами, иначе рефакторинг и какая-либо миграция версий PHP превращаются в боль а менеджеры воспринимают такие предложения как бред сумасшедшего.
Есть разные проекты, есть разные подходы.
Что до производительности, смотря на чем проект. Производительность может и просесть, если не повезет. Но обычно переход с php5.4+apc (для 5,3 у меня такой информации нету) на 5,5+opcache добавляет каких 5%-10%. Кто-то говорит что их сайтики на Drupal/Wordpress начали работать шустрее и на 20%. Синтетика в определенных тестах показывает 50% прирост. Как по мне это приятный бонус.
Правда все это имеет смысл только если проект покрыт тестами, иначе рефакторинг и какая-либо миграция версий PHP превращаются в боль а менеджеры воспринимают такие предложения как бред сумасшедшего.
Есть разные проекты, есть разные подходы.
Что до производительности, смотря на чем проект. Производительность может и просесть, если не повезет. Но обычно переход с php5.4+apc (для 5,3 у меня такой информации нету) на 5,5+opcache добавляет каких 5%-10%. Кто-то говорит что их сайтики на Drupal/Wordpress начали работать шустрее и на 20%. Синтетика в определенных тестах показывает 50% прирост. Как по мне это приятный бонус.
Вот за этот комментарий спасибо и плюсик от меня.
Пятничное игривое настроение дало хотя бы один приятный комментарий. Что же до сути:
Вот здесь кроется вся боль.
По этому поводу — не всё только юнит-тестами делано, придется прогонять ВСЕ типы тестов заново, что так же влечет немало расходов. В общем, пока что мой опыт говорит о том, что чаще всего выгоднее оставлять старую версию.
Опять таки есть проект, написанный еще в 2006 году, само собой его никто не оставил по сей день на 5.1.6, но и небыло такого, что с выходом новой версии его тут же обновляли, отнюдь. По-моему, он обновился с выходом 5.3, а это довольно большой срок. Здесь же чуть по выше, я увидел слезы: «Надо срочно обновляться».
Пятничное игривое настроение дало хотя бы один приятный комментарий. Что же до сути:
Правда все это имеет смысл только если проект покрыт тестами, иначе рефакторинг и какая-либо миграция версий PHP превращаются в боль а менеджеры воспринимают такие предложения как бред сумасшедшего.
Вот здесь кроется вся боль.
Добавить еще один прогон тестов на новой версии PHP на CI сервере пробле ни у кого не составит.
По этому поводу — не всё только юнит-тестами делано, придется прогонять ВСЕ типы тестов заново, что так же влечет немало расходов. В общем, пока что мой опыт говорит о том, что чаще всего выгоднее оставлять старую версию.
Опять таки есть проект, написанный еще в 2006 году, само собой его никто не оставил по сей день на 5.1.6, но и небыло такого, что с выходом новой версии его тут же обновляли, отнюдь. По-моему, он обновился с выходом 5.3, а это довольно большой срок. Здесь же чуть по выше, я увидел слезы: «Надо срочно обновляться».
Но иногда могут возникать труднорешаемые проблемы, когда хостинг сам себе переходит на более новую версию. У меня возникли проблемы с некоторыми плагинами для cms, после перехода с 5,2 на 5,3 хостером. Пришлось переписывать функции, которых уже не было в новой версии PHP или был новый синтаксис. А у кого десятки и сотни сайтов? Поэтому правильный подход для хостингов — это предоставить выбор, какую версию php для какого сайта поддерживать. И просто рекомендовать перейти на более новую версию. А если хостинг сам перевел на новую версию (как было в моем случае), и сразу перестали работать 10 сайтов? Кто виноват? И за какой сайт браться в первую очередь?
Возможно, я не в реальном мире живу, но мы планируем «переезд» на 5.6 в течение месяца по большинству проектов.
Я бы советовал подождать хотя бы до минорной единицы\двойки
Ну, я сказал ориентировочное время. Разумеется, мы подождем отзывов сообщества, прежде чем накатывать php 5.6. Хотя на своих персональных проектах я собираюсь этим заняться на выходных.
Но в последнее время PHP очень сильно радует, в том числе и тем, насколько хорошо и быстро они вносят фиксы. Поэтому нам кажется, что в течение месяца будет видно, как обстоят дела с 5.6 версией и мы примем решение о конкретных сроках внедрения ее на проектах.
С нетерпением жду 7-й версии, которая вроде как может выйти к концу 2015 — началу 2016.
Но в последнее время PHP очень сильно радует, в том числе и тем, насколько хорошо и быстро они вносят фиксы. Поэтому нам кажется, что в течение месяца будет видно, как обстоят дела с 5.6 версией и мы примем решение о конкретных сроках внедрения ее на проектах.
С нетерпением жду 7-й версии, которая вроде как может выйти к концу 2015 — началу 2016.
Ну помимо изменённого ядра — туда ещё намереваются добавить AST, так что думаю ожидание релиза новой (супер)мажорной версии можно чуть отложить.
Реализация AST уже готова и будет в ближайшее время смержена в мастер.
Судя по постскриптуму к этому сообщению: http://news.php.net/php.internals/76874, это уже сделано.
5.2!!! на неделе пнул клиента. ну нельзя же на таком старье то сидеть
У меня на сервере проекта 5.5.
5.3 уже очень давно не наблюдал.
Что это у вас за реальный мир?
P.S.
Сейчас крупные проекты берут себе сервера, маленькие и средние облачные хранилища.
Везде все настраивается руками, ставишь то что надо.
5.3 разве что на хостингах есть.
Я уже оч. привык писать массивы [] =)
5.3 уже очень давно не наблюдал.
Что это у вас за реальный мир?
P.S.
Сейчас крупные проекты берут себе сервера, маленькие и средние облачные хранилища.
Везде все настраивается руками, ставишь то что надо.
5.3 разве что на хостингах есть.
Я уже оч. привык писать массивы [] =)
А zend loader все еще на 5.4 :(
Продавцы блобов должны страдать.
Продавцы то не страдают, страдают разработчики.
Я довольно много видел этих «защищенных» продуктов. Во всех случаях единственной реальной причиной использовать zend guard могло бы быть только то, что такой код стыдно показывать.
То есть вы считаете, что проприетарное ПО является таким только из-за «плохого» качества кода?
Нет, не считаю.
Во-первых, проприетарным ПО является согласно его лицензии, а не по использованию каких-либо технических средств. Скажем, те же vBulletin или XenForo — проприетарные продукты.
Во-вторых, я говорю о том, что видел. А я не видел ни одного продукта, защищенного с помощью zend guard или подобных средств, качество кода которого можно было бы охарактеризовать как-то иначе, чем «полный ужас». Никаких обобщений, просто статистика.
Во-первых, проприетарным ПО является согласно его лицензии, а не по использованию каких-либо технических средств. Скажем, те же vBulletin или XenForo — проприетарные продукты.
Во-вторых, я говорю о том, что видел. А я не видел ни одного продукта, защищенного с помощью zend guard или подобных средств, качество кода которого можно было бы охарактеризовать как-то иначе, чем «полный ужас». Никаких обобщений, просто статистика.
А кем вы работаете, что вы видели много кода, закрытого с помощью zend guard? Просто может быть специфика вашей деятельности такова, что к вам попадали только «плохие» проекты? Ну может «хорошим» проектам просто не нужны ваши услуги, вот вы их и не видели?
Нет особой проблемы увидеть код, закрытый с помощью zend guard: опкоды сдампить не проблема, а дальше — дело техники. :) Обфускация не мешает понять качество кода.
Но ваше предположение имеет смысл: в основном задача была от этих проектов избавиться, и с них мигрировать — а поскольку любители zend guard-ов еще очень любят устроить vendor lock, и без реверс-инжиниринга не обойтись. Ну давайте название хорошего проекта, а я уж как-нибудь найду и посмотрю ;)
Но ваше предположение имеет смысл: в основном задача была от этих проектов избавиться, и с них мигрировать — а поскольку любители zend guard-ов еще очень любят устроить vendor lock, и без реверс-инжиниринга не обойтись. Ну давайте название хорошего проекта, а я уж как-нибудь найду и посмотрю ;)
Отлично. Мы на 5.6 девелопим с первой беты. Теперь можно и продакшн через пару миноров обновить. Всех поздравляю, ждём phpng.
При определении массива как свойства класса ключи массива не будут перезаписаны литералами массива.
Я наверное еще не проснулся, но не понимаю смысл этой фразы. Кто-нибудь пояснит?
bugs.php.net/bug.php?id=66015 — вот этот баг закрыли
Занятно.
Возведение в степень вычисляется справа налево.
Возведение в степень вычисляется справа налево.
2 ** 3 ** 2 == 512; 2 ** (3 ** 2) = 2 ** 9 = 512
В языках программирования это довольно стандартно… Хотя в excel, скажем, всё наоборот…
А что вас удивляет? Математическая запись, например, предполагает именно такой порядок операций. Да и в языках программирования это типичная практика. Разве что только в excel порядок операций обратный.
Вот прямо сейчас выполню эту операцию в консоли:
ruby:
irb(main):002:0> 2 ** 3 ** 2
=> 512
perl:
MacBook-Pro-Dmitry:~ dmitry$ perl -e 'print(2 ** 3 ** 2); print("\n")';
512
python:
MacBook-Pro-Dmitry:~ dmitry$ python -c 'print(2**3**2)'
512
Вот прямо сейчас выполню эту операцию в консоли:
ruby:
irb(main):002:0> 2 ** 3 ** 2
=> 512
perl:
MacBook-Pro-Dmitry:~ dmitry$ perl -e 'print(2 ** 3 ** 2); print("\n")';
512
python:
MacBook-Pro-Dmitry:~ dmitry$ python -c 'print(2**3**2)'
512
В любом случае, со скобками правильнее и понятнее. Но и последовательность вычислений в языках полезно знать. Можно иногда значительно оптимизировать производительность приложения.
А что там вообще с json? Его обратно вернули в ядро? А то мы используем внешний модуль
А его удаляли из ядра? О_о
Тут ничего об этом не вижу.
Тут ничего об этом не вижу.
Лучше бы описали новые возможности.
Пробую во всю 5.6 очень даже нравится. Вот только проблема с DLE, их надо обновлять, иначе кучу ошибок говорят. Например, я привык к NetBeans, именно к NetBeans 7.2.1, от последних версий мурашки по коже. Теперь вот не знаю, выбрать другую DLE или не использовать новые фишки 5.6. Если у кого нибудь есть плагин для netbeans 7.2.1 для поддержки PHP 5.6 буду очень даже признателен.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел финальный релиз PHP 5.6.0