Phalcon 2 вышел

http://blog.phalconphp.com/post/116664774400/phalcon-2-released
  • Перевод


Ожидание закончилось! Phalcon 2.0 уже здесь!

После более чем года разработки, мы невероятно рады объявить о выпуске финального релиза Phalcon 2.0.

Те, кто следил за проектом внимательно, знают, что это было подвигом:

  • Создали совершено новый язык программирования — Zephir, который позволяет разработчикам писать расширения для PHP.
  • Нам пришлось переписать большую часть Phalcon 1.3.x, мы старались оставить тот же функционал, как и прежде, чтобы гарантировать обратную совместимость и упростить миграцию.
  • Zephir был значительно скорректирован после того, как мы перевели разработку на него, теперь он предлагает разработчикам больше функций и возможностей для разработчиков.
  • Есть множество дополнительных фич, которые были реализованы в версии 2.0, за что мы очень благодарны коллабораторам!


Результаты, которыми мы можем гордиться:
  • Расширение Phalcon 2.0 также совместим с PHP (и даже больше) как и раньше
  • Zephir позволяет разработчикам писать собственные расширения без необходимости в знаниях C.

Установка


Данная версия может быть установлена из ветки 2.0.0, если у вас еще не установлен Zephir, следуйте следующим инструкциям:

git clone http://github.com/phalcon/cphalcon
git checkout 2.0.0
cd ext
sudo ./install

Стандартный метод установки также работает:

git clone http://github.com/phalcon/cphalcon
git checkout 2.0.0
cd build
sudo ./install

Если же Zephir уже установлен:

git clone http://github.com/phalcon/cphalcon
git checkout 2.0.0
zephir build

Обратите внимание, что при запуске установочного скрипта, предыдущие версии Phalcon будут удалены.

DLL-библиотека для Windows доступна на странице загрузки.

Смотрите руководство по обновлению для получения дополнительной информации об установке и обновлении до версии 2.0.

Что дальше


Наш график релизов предусматривает выпуск обновлений раз в один или два месяца, исправления безопасности, конечно же, будут происходить с максимально возможной скоростью. Цели просты: мы хотим реализовать наиболее востребованные сообществом функции.

Минорные изменения и исправления будут выходить по мере возможности. Также мы работаем над переходом к модели LTS-релизов для нашего сообщества.

Наконец, мы собираемся начать разработку под PHP7, это переломный для всех нас момент и Zephir будет соответствовать всем требованиям разработчиков к моменту релиза 7й версии. Решение этой задачи потребует большой подготовки и у нас еще много работы впереди, но мы мотивированы как никогда и полны решимости реализовать в Zephir все те преемущества, которые предложит новый PHP.

Заключение и благодарности


Мы очень рады этому обновлению и ясно видим путь развития нашего фреймворка. Больше спасибо всем участникам! Без вас мы бы не справились. И конечно же, мы хотели бы поблагодарить всех, кто тестировал alpha/beta-версии и RC, искал баги, писал репорты и всячески помогал с обратной связью. Мы очень надеемся, что вам понравится этот релиз.

Мы хотели бы выразить нашу глубокую признательность за огромные усилия, миграции и тестирования кода в этой версии следующим людям:


Еще раз спасибо всем!
Наслаждайтесь Phalcon 2 <3
Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 68
    +4
    > Zephir позволяет разработчикам писать собственные расширения без необходимости в знаниях C.
    Но при этом нужна знания Zephir, который никто не знает, в то время как C знает большинство профессиональных программистов (целевая аудитория этого фреймворка).

    То, что фреймворк представлен нативным модулем, большинство воспринимает как минус, а не плюс: производительности не сильно прибавляет, а нажать в отладке Step Into на строке с вызовом фреймворка нельзя.
      +5
      производительности не сильно прибавляет, а нажать в отладке Step Into на строке с вызовом фреймворка нельзя.

      Троллинг? Более чем в 10 раз производительнее Symfony2 и в 6 раз меньше потребление памяти.
      Что касается отладки, это уже задача разработчиков фреймворка. Тот же Sf2 не многие отлаживают, проще зарепортить issue
        0
        Нет, не троллинг.
        И с Symfony сравнивать некорректно — разные задачи. Для задач на симфони производительность PHP-кода не важна — узкое место будет во внешних сервисах.
        Сравните с lumen.laravel.com
          +1
          С чего вы взяли, что разные задачи?
          Про узкое место во внешних сервисах и БД я как-то уже устал слушать — возьмите любое приложение и пройдитесь профайлером, потом мы сможем конструктивно обсудить их узкие места.
          Что касается люмена, то фалкон в 4 раза производительнее, и да, люмен позиционирует себя как микрофреймворк в отличие от фалкона
            +2
            Что касается люмена, то фалкон в 4 раза производительнее, и да, люмен позиционирует себя как микрофреймворк в отличие от фалкона

            Работал я с первой веткой, и не скажу что Phalcon это самодостаточный фреймворк. Взять Phalcon, допилить под себя(на уровне php), установить несколько сторонних библиотек, и понять что профита в производительности действительно нет.
              +1
              В Фалконе есть Micro Application, так что можно сравнивать. Другое дело, что нет исходника бенчмарка Люмена (во всяком случае я не вижу :) ), так что сравнить будет сложно.
                0
                Когда работал с Phalcon, использовал Micro Application, и всё-равно у меня получалась своя нехилая прослойка, так что считаю что b его некорректно сравнивать с Люменом. Куда интересней было бы сравнить с точной копией, написаной на PHP.
                  0
                  И что же такого есть в lumen, чего нет в phalcon micro? Потому как простейшие примеры на обоих фреймворках выглядят идентично.
              0
              > Сравните с lumen.laravel.com
              С ним сравнивать надо phalcon micro mvc, чтобы было честно.
              +7
              Мы же с вами понимаем, что обычно в проекте по мимо самого фреймворка куча дополнительных модулей, подтянутых с помощью composer, плюс наш код, а значит скорость работы не будет x10.
                –2
                Фалкон вполне себе самодостаточен: на большинство рядовых задач можно обойтись минимум сторонних библиотек.
                Что касается своей бизнес-логики, то Фабьен сам признавался, что основная нагрузка при обработке запроса ложится на фреймворк (инициализацию), он пытается вести какие-то работы в этом направлении, но, как видим, пока результатов нет, и оверхед этот остается
                  +5
                  Скажите, вы сами видели проекты, в которых по мимо самого фреймворка и вашего кода нет ничего дополнительно поставленного через composer? Речь не о проектах уровня «Hello world!».

                  Я о том, что понятно — сам фреймворк быстрый, sf2 курит в сторонке, все дела… Но в реальности все немножко иначе и надеяться на x10 ускорение не приходится.
                    0
                    Понятно, что будет какое-то падение, но я еще раз повторяю, большую часть времени занимает инициализация фреймворка, сторонние либы чаще всего включаются частично в зависимости от страниц. Пусть ускорение будет x5-x8 — вас такой ответ устроит? :D
                      +2
                      Я не замерял… А раз так — конкретных иксов я не скажу и устроить ваш ответ меня не может без прогнанных тестов. Я говорил лишь о том, что x10 unreal в реальном мире.
                        +1
                        Ну так и симфони гибче и масштабнее, там больше кода инициализации, различных проверок.
                        Все эти цифры приблизительны, но глупо их игнорировать
                          0
                          Кто сказал, что я игнорирую их?! Phalcon 2 крут в плане скорости, но сейчас речь не про это. Речь про то, что важно здраво оценивать то, что напишут тестеры и понимать, что синтетика никогда не даст реальных результатов и поэтому важно думать прежде чем выбирать тот или иной фреймворк для вашей задачи. Не более.
                      –3
                      Мы, не используем Composer. Не вижу смысла тянуть в нормальный проект все эти зависимости.
                      Если Вы пишете код с правилом — «лишь бы было и работало», тогда композер подойдёт и ваш подход подойдёт и sf2 в том числе.
                      Но в сколько нибудь нагруженном проекте Ваш подход испытает очень большие трудности.
                        +1
                        Я правильно понимаю вы противник composer way? Каким путем идете вы?

                        Можете рассказать какие именно огромные трудности испытает нагруженный проект (серьезно интересно)?

                        По моему composer как раз не для «лишь бы было и работало», а как раз для того, чтобы заюзать удобный интеллектуальный менеджер «пакетов», в котором есть все для дальнейшей жизни проекта (install, upgrade, remove, dependencies).
                          –3
                          Интереcные вопросы, получается короткое интервью, я не являюсь автором проекта и его архитектором по сути, но всё же на некоторые вопросы могу ответить точно.

                          1. Совершенно верно, мы не используем composer, весь код проекта «изобретается заново», где десятки слоёв абстракций заменяются одним простым и удобным, целевым решением (функцией или классом).

                          2. У каждого свои трудности, в нашем случае — это средства :) Их всегда — не достаточно, мы не может взять и прыгнуть через голову, приходится идти небольшими шагами.

                          3. Менеджер пакетов и автоматический контроль зависимостей требует большое количество ресурсов, а мы не любим их тратить впустую :) Приведу пример: мы ищем в композере класс, который позволял бы сделать crop картинки и находится класс, который позволяет делать с изображением всё что угодно, но нам не нужен этот огромный класс, нам нужен только crop с уже известной степенью сжатия и известным путём для файла, а так же алгоритмом «вырезания картинки». Таким образом мы выбрасываем «удобный» класс композера на 1500 строк кода, а так же 10 уровнями абстракции и заменяем его функцией на 150/200 строк.
                            +3
                            Т.к. суперкласс в index.php? Насколько «большой» ваш проект? ))
                            Опыт показывает, что сперва берется функция crop, потом через месяц попросили ввести rotate, потом scale и через пол года вы написали ту самую библиотеку, только криво, на костылях, тогда как та либа покрыта тестами, проверена сообществом 100500 раз и используется в топовых проектах. Пройдено уже ;D
                              0
                              Если проект одноразовый, то возможно и так прокатывает. Потом проект приходит к кому-то на support и заказчик слышит волшебную фразу: «Мы щас вам тут все перепишем на %framework_name%»
                                0
                                Не надо кидаться из крайности в крайность, нет никакого супер index.php :) Большой ли, не знаю что для Вас большой проект, в php файлах насчитал 75000 строк, фреймворка — нет, все базовые классы реализованы в 2-3 тысячах строк.

                                Rotate не делаем, если понадобится добавить 1-2 строку кода с поворотом угла будет не так уж и сложно, итого получаем 30 строк кода включая комментарии, для древнющего gd :)
                                  +1
                                  Я не хотел кидаться в крайности :) Просто на моем текущем месте работы (когда я пришел туда) четко сказали, что надо писать на статике, типо быстро и просто и т.д. С тех пор прошло уже 4 года, конечно, и сейчас часть того ужасного легаси уже переписана, но часть осталась, как шрам на теле :)
                                  И по опыту опять же, поначалу так и было, что мол проще написать 1 функцию, чем искать либы и т.д. В итоге все это обрастало костылями, никаких абстракций же, лишние усложнения и т.д.
                                  А я по натуре такой программист, который ищет готовые решения всегда. Я велосипед писать буду только если он спасет от падения метеорита )) и то скорей всего сперва загуглю… Поэтому для меня вопрос болезненный ))
                                0
                                Если производительность так уж важна, то зачем вообще писать на PHP? Си ваше все. В ином случае получается экономия на спичках.
                                  0
                                  еще не пришли к этому, когда возьмут за горло, так оно и будет :)
                                  +2
                                  Менеджер пакетов и автоматический контроль зависимостей требует большое количество ресурсов, а мы не любим их тратить впустую :)

                                  Вы имеете ввиду ресурсы компьютера или человеческие ресурсы? Поскольку composer лишь средство для установки PHP библиотек, ваша фраза звучит как «все, что написали другие, по умолчанию раздуто и медленно». Или мне показалось?

                                  Таким образом мы выбрасываем «удобный» класс композера на 1500 строк кода, а так же 10 уровнями абстракции и заменяем его функцией на 150/200 строк.

                                  Я правильно понимаю, что вы исповедуете NIH философию?
                                    0
                                    Возможно речь про ресурсы шла в разрезе обертки, которую создает composer для autoload'а всех штуковин из vendor. Поправьте если не так.
                                      +1
                                      Да вот я тоже не очень понял. Не думаю, что обертка composer будет тяжелой. Особенно, если большая часть либ с PSR-4 правилами автозагрузки.
                                      –2
                                      Имею ввиду ресурсы компьютера.

                                      нет, вы не правильно понимаете, мы используем философию целевого программирования, когда код пишется для какой-то уже известной цели, а не для абстрактных, возможных углов его применения.

                                      Как обычно для хабры, стянулись гуру домашнего программирования и перевернули всё так, как им удобно, считая только их подход правильным, всё будет хорошо, никуда Ваш композер не денется, как писали 90% людей на нём или используя его и PSR-4, так и будут дальше.
                                      Однако — есть проекты, в которых всё это не нужно, не нужно всех под одну гребёнку, каждой задаче должно быть своё решение, впрочем, зачем я это всё объясняю, думаю даже начинать не стоило.
                                        +1
                                        зачем я это всё объясняю, думаю даже начинать не стоило.

                                        Почему не стоило? У вас есть позиция, почему бы ее не разъяснить?

                                        Мне непонятно, каким образом отказ от composer экономит ресурсы компьютера. Непонятно также, каким образом в разработке помогает NIH-принцип.

                                        И мне бы хотелось понять вашу точку зрения.
                                      +3
                                      Вам везет)) Серьезно!

                                      Мой опыт и опыт всех моих знакомых разработчиков показывает, что обычно у нас нет времени на трюки с выпилкой только нужного функционала из подключаемых либ. Я о том, что скажем в проекте с 20-30 зависимостями (мы понимаем, что это не предел для долго играющих проектов) из composer у нас просто физически нет времени на описанные выше действия.

                                      Часто приходится быстро находить решения для задач, чтобы клиент остался доволен и проект завершился во время. Конечно, это вопрос менеджмента на проекте и возможно здесь есть над чем задуматься. Хотя опять же ваш подход как я думаю в теории должен сильно увеличивать сроки, даже с учетом, что все ходовые штуки вы уже давно выпилили и юзаете от проекта к проекту. Или нет?
                                        0
                                        Да, сроки большие, всё связано с тем, что это не аутсорсинг проект, задачи решаются постепенно по мере их необходимости, код пишется целевой максимально короткие сроки, главный упор на бекенде — бытсродействие, на фронтенде — функционал.

                                        А для аутсорсинг проектов конечно же нет смысла изобретать что-то, можно брать всё готовое, лишь бы работало)))
                                0
                                Для этого надо исключить инициализацию при каждом запросе (отказаться от php always die) и использовать подход одноразовой инициализации как в node-js: phpDaemon, reactphp, prefork.
                            +3
                            Я просто оставлю это здесь
                            github.com/kenjis/php-framework-benchmark
                              0
                              Хотелось бы увидеть сравнение скажем с Django.
                                0
                                Нет-нет, значительно более хотелось бы увидеть сравнении с Flask!
                                0
                                Как часто заказывают hello world проекты? почему?
                                В большом проекте будут разного вида кэши (не видел пока ни одного крупного проекта без кэширования). И symfony2 выдаст уже совсем другие результаты.
                                А если к ней прикрутить reactphp (по умолчанию никаких утечек памяти в симфе — проверяли), то можно будет уже и на верхних строках оказаться.
                                Интересно, если бы кто такой тест сделал, у кого есть время и скиллы потестировать?
                                  +1
                                  Тоже самое можно сказать про любой другой нормальный фреймворк.
                                    0
                                    я о том же, просто на примере php, т.к. работаю постоянно с ней
                                  0
                                  Это если читстый фреймворк запускать — будет такой показатель.

                                  Если написать своего кода на PHP сверху да подключить несколько компонентов Symfony или Zend для решения задач и все, скорости уровнялись.
                                  Для микро фреймворков то же самое.
                                  +5
                                  Но при этом нужна знания Zephir, который никто не знает

                                  Zephir, судя по документации настолько похож php, что любой php-программист разберется в нем очень быстро, в то время как научиться писать расширения на Си намного сложнее, особенно для людей плохо знающих Си
                                    +1
                                    В C норм, а вот в ту штуку на которой пишутся extension прям это кровь из глаз какое-то :(
                                      0
                                      Да ладно вам, даже на сишарп похоже)
                                  +12
                                  sudo ./install

                                  Вот за такие рекомендации хоть бери руки отрывай. Потом же его не выпилишь с системы. Писал разработчикам давным давно — игнорируют.

                                  Сделали бы хоть пару пакетов — deb и rpm, пусть даже компилируются при установке (как Java ставится с ppa в Ubuntu — в процессе установки скачивается, распаковывается куда нужно и конфигурируется), но чтобы можно было легко поставить, а потом легко снести под корень.
                                    0
                                    Уже изобрели эту штуку — ok google what is checkinstall?
                                      0
                                      Да, я в курсе (когда-то пробовал, так и не получилось собрать, хотя давно это было), а вот разработчики по ходу нет.
                                        0
                                        Да и забить вообще на него. Docker спасёт отца русской демократии.
                                          0
                                          Я собирал под Docker его (не хочется так мусорить в рабочей системе), так на хосте полученное расширение (hello world) приводило постоянно к segmentation fault, а я-то хотел один часто используемый класс переписать…
                                            0
                                            Значит где-то что-то не так. Иссуя на гитхабе создана?
                                              0
                                              Да, сразу несколько по разным поводам, но так ничего и не получил в ответ: github.com/phalcon/zephir/issues/663
                                              Зато метку «not tested» поставили через 27 дней со дня репорта. Странное отношение…
                                                +1
                                                На самом деле, как один из активных контрибьюторов могу сказать, что разбирать баги под zephir самое не приятное занятие.
                                                Особенно радует, когда разработчики не следуют описанной процедуре сообщения о багах:
                                                github.com/phalcon/zephir/blob/master/CONTRIBUTING.md#bugs
                                                Помимо описанных пунктов, желательно сразу добавить C-код сгенерированный/ссылку на проект/PR с тестом.
                                        0
                                        Хорошая штука, но последняя версия вышла 6 лет назад. Оно работает нормально?
                                      +1
                                      Куча софта нет в пакетах — это нормально, по тому что под это дело надо выделять человека чтобы он этим занимался и поддерживал, по этому логично что они пишут фреймворк, а если есть желающие помочь делом то они участвуют.

                                      А для сборки пакетов «для личных нужд» есть достаточно инструметов: fmp, checkinstall…
                                        0
                                        Сделали бы хоть пару пакетов

                                        Все же есть phalconphp.com/en/download, только еще не успели собрать под версию 2.0
                                        0
                                        Интересно, а как Zephir подружить с другими модулями или библиотеками, например использовать Redis или SQLite? При быстром обзоре документации ничего подобного не заметил…
                                        0
                                        Вопрос — а zephyr расширение можно использовать без установленного phalkonphp?
                                        Ну то есть собрать его, и перенести .so
                                          +1
                                          Можно. Zephir — независимый проект.
                                            0
                                            Удалено. Я буду обновлять комментарии перед отправкой…
                                            0
                                            Насколько эта штука Testable? И как удобно писать тесты под код с Phalcon?
                                              0
                                              Все нормально, а в чем Вы видите проблему?
                                                +1
                                                Извините, я не вижу проблему. Просто интересует есть ли уже готовые практики на этот счет. Скорее про community power вопрос.
                                                  0
                                                  Все тоже самое, что и в других фреймворках, просто часть кода поставляется бинарником в виде экстеншна (например, как встроенный в PHP класс DateTime). Для IDE есть devtools, с ними нормально работает автоподстановка и быстрый доступ к докам.
                                                0
                                                По опыту пиления проекта на Флаконе (как мы его называем промеж себя) скажу, что иногда бывают сложности. Ясное дело: F7 не сделаешь, внутрь кода не попадешь. Потому довольно часто приходится лезть собственно в исходники Флакона (благо написано легко и непринужденно, так что читать нетрудно). Потому версия 2 в этом смысле выглядит явно привлекательнее — именно в силу того, что написана на более read-friendly языке. Сообщество слабое, процентов на 70 приходилось искать ответ своими силами. Официальный форум содержит в основном весьма элементарные вещи, а время, чтобы ждать ответ, не всегда есть. Да, еще большой минус — разработчики весьма фривольно относятся к обратной совместимости. В версии 1.3.* по сравнению с версией 1.2.* поменяли набор аргументов в паре методов (на память только какой-то log formatter приходит), что реально затрудняет переход на новую версию, когда уже есть работающий проект на проде.
                                                  +2
                                                  Скорее всегда, на том этапе было активное развитие фреймворка, поэтому совместимость была плохая. Думаю, сейчас они будут делать максимальную обратную совместимость из-за возросшей популярности.
                                                  +1
                                                  Вполне себе ок, конечно, иногда не удобно, что не видно полноценного стектрейса при ошибках, но по идее Phalcon DevTools как-то решают эти вопросы. Во всем остальном — тестируется как любой другой проект. Кроме того, есть модуль для тестирования для Codeception с демо-проектом: codeception.com/docs/modules/Phalcon1

                                                  Ах, ну да, следует обновить его до Phalcon2 :)

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое