Ожидание закончилось! 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, искал баги, писал репорты и всячески помогал с обратной связью. Мы очень надеемся, что вам понравится этот релиз.
Мы хотели бы выразить нашу глубокую признательность за огромные усилия, миграции и тестирования кода в этой версии следующим людям:
- Andres Gutierrez
- Nikolaos Dimopoulos
- Vladimir Kolesnikov
- Eduar Carvajal
- Dreamszhu
- Dmitry Patsura
- Vladimir Khramov
- Piotr Gasiorowski
- Olivier Monaco
- Sid Roberts
- Ivan Zubok
- Max Galbusera
- Yvan Taviaud
- Rian Orie
- Brainformatik GmbH
- Mariusz Laczak
- Nikolay Kirsh
- Kamil Skowron
- Serghei Iakovlev
- Richard Laffers
- Nikita Vershinin
- Olivier Garbe
- Robert Smolarek
- Simon Karberg
- Soufiane Ghzal
- Kenji Suzuki
- Carlos Guimaraes
Еще раз спасибо всем!
Наслаждайтесь Phalcon 2 <3
Комментарии (68)
nazarpc
18.04.2015 17:57+12sudo ./install
Вот за такие рекомендации хоть бери руки отрывай. Потом же его не выпилишь с системы. Писал разработчикам давным давно — игнорируют.
Сделали бы хоть пару пакетов — deb и rpm, пусть даже компилируются при установке (как Java ставится с ppa в Ubuntu — в процессе установки скачивается, распаковывается куда нужно и конфигурируется), но чтобы можно было легко поставить, а потом легко снести под корень.
garex
18.04.2015 19:15Уже изобрели эту штуку — ok google what is checkinstall?
nazarpc
18.04.2015 21:31Да, я в курсе (когда-то пробовал, так и не получилось собрать, хотя давно это было), а вот разработчики по ходу нет.
garex
18.04.2015 21:40Да и забить вообще на него. Docker спасёт отца русской демократии.
nazarpc
18.04.2015 21:43Я собирал под Docker его (не хочется так мусорить в рабочей системе), так на хосте полученное расширение (hello world) приводило постоянно к segmentation fault, а я-то хотел один часто используемый класс переписать…
garex
18.04.2015 21:44Значит где-то что-то не так. Иссуя на гитхабе создана?
nazarpc
18.04.2015 21:48Да, сразу несколько по разным поводам, но так ничего и не получил в ответ: github.com/phalcon/zephir/issues/663
Зато метку «not tested» поставили через 27 дней со дня репорта. Странное отношение…
hell0w0rd
19.04.2015 12:33+1На самом деле, как один из активных контрибьюторов могу сказать, что разбирать баги под zephir самое не приятное занятие.
Особенно радует, когда разработчики не следуют описанной процедуре сообщения о багах:
github.com/phalcon/zephir/blob/master/CONTRIBUTING.md#bugs
Помимо описанных пунктов, желательно сразу добавить C-код сгенерированный/ссылку на проект/PR с тестом.
FractalizeR
19.04.2015 11:47Хорошая штука, но последняя версия вышла 6 лет назад. Оно работает нормально?
Claud
19.04.2015 10:51+1Куча софта нет в пакетах — это нормально, по тому что под это дело надо выделять человека чтобы он этим занимался и поддерживал, по этому логично что они пишут фреймворк, а если есть желающие помочь делом то они участвуют.
А для сборки пакетов «для личных нужд» есть достаточно инструметов: fmp, checkinstall…
iGusev Автор
20.04.2015 12:43Сделали бы хоть пару пакетов
Все же есть phalconphp.com/en/download, только еще не успели собрать под версию 2.0
AgentSIB
18.04.2015 21:00Интересно, а как Zephir подружить с другими модулями или библиотеками, например использовать Redis или SQLite? При быстром обзоре документации ничего подобного не заметил…
KlonD90
19.04.2015 12:50Насколько эта штука Testable? И как удобно писать тесты под код с Phalcon?
Yeah
19.04.2015 22:52По опыту пиления проекта на Флаконе (как мы его называем промеж себя) скажу, что иногда бывают сложности. Ясное дело: F7 не сделаешь, внутрь кода не попадешь. Потому довольно часто приходится лезть собственно в исходники Флакона (благо написано легко и непринужденно, так что читать нетрудно). Потому версия 2 в этом смысле выглядит явно привлекательнее — именно в силу того, что написана на более read-friendly языке. Сообщество слабое, процентов на 70 приходилось искать ответ своими силами. Официальный форум содержит в основном весьма элементарные вещи, а время, чтобы ждать ответ, не всегда есть. Да, еще большой минус — разработчики весьма фривольно относятся к обратной совместимости. В версии 1.3.* по сравнению с версией 1.2.* поменяли набор аргументов в паре методов (на память только какой-то log formatter приходит), что реально затрудняет переход на новую версию, когда уже есть работающий проект на проде.
egorsmkv
19.04.2015 23:49+2Скорее всегда, на том этапе было активное развитие фреймворка, поэтому совместимость была плохая. Думаю, сейчас они будут делать максимальную обратную совместимость из-за возросшей популярности.
Davert
20.04.2015 14:14+1Вполне себе ок, конечно, иногда не удобно, что не видно полноценного стектрейса при ошибках, но по идее Phalcon DevTools как-то решают эти вопросы. Во всем остальном — тестируется как любой другой проект. Кроме того, есть модуль для тестирования для Codeception с демо-проектом: codeception.com/docs/modules/Phalcon1
Ах, ну да, следует обновить его до Phalcon2 :)
OnYourLips
> Zephir позволяет разработчикам писать собственные расширения без необходимости в знаниях C.
Но при этом нужна знания Zephir, который никто не знает, в то время как C знает большинство профессиональных программистов (целевая аудитория этого фреймворка).
То, что фреймворк представлен нативным модулем, большинство воспринимает как минус, а не плюс: производительности не сильно прибавляет, а нажать в отладке Step Into на строке с вызовом фреймворка нельзя.
shoomyst
Троллинг? Более чем в 10 раз производительнее Symfony2 и в 6 раз меньше потребление памяти.
Что касается отладки, это уже задача разработчиков фреймворка. Тот же Sf2 не многие отлаживают, проще зарепортить issue
OnYourLips
Нет, не троллинг.
И с Symfony сравнивать некорректно — разные задачи. Для задач на симфони производительность PHP-кода не важна — узкое место будет во внешних сервисах.
Сравните с lumen.laravel.com
shoomyst
С чего вы взяли, что разные задачи?
Про узкое место во внешних сервисах и БД я как-то уже устал слушать — возьмите любое приложение и пройдитесь профайлером, потом мы сможем конструктивно обсудить их узкие места.
Что касается люмена, то фалкон в 4 раза производительнее, и да, люмен позиционирует себя как микрофреймворк в отличие от фалкона
qRoC
Работал я с первой веткой, и не скажу что Phalcon это самодостаточный фреймворк. Взять Phalcon, допилить под себя(на уровне php), установить несколько сторонних библиотек, и понять что профита в производительности действительно нет.
Yeah
В Фалконе есть Micro Application, так что можно сравнивать. Другое дело, что нет исходника бенчмарка Люмена (во всяком случае я не вижу :) ), так что сравнить будет сложно.
qRoC
Когда работал с Phalcon, использовал Micro Application, и всё-равно у меня получалась своя нехилая прослойка, так что считаю что b его некорректно сравнивать с Люменом. Куда интересней было бы сравнить с точной копией, написаной на PHP.
Yeah
И что же такого есть в lumen, чего нет в phalcon micro? Потому как простейшие примеры на обоих фреймворках выглядят идентично.
akden
> Сравните с lumen.laravel.com
С ним сравнивать надо phalcon micro mvc, чтобы было честно.
itcrab
Мы же с вами понимаем, что обычно в проекте по мимо самого фреймворка куча дополнительных модулей, подтянутых с помощью composer, плюс наш код, а значит скорость работы не будет x10.
shoomyst
Фалкон вполне себе самодостаточен: на большинство рядовых задач можно обойтись минимум сторонних библиотек.
Что касается своей бизнес-логики, то Фабьен сам признавался, что основная нагрузка при обработке запроса ложится на фреймворк (инициализацию), он пытается вести какие-то работы в этом направлении, но, как видим, пока результатов нет, и оверхед этот остается
itcrab
Скажите, вы сами видели проекты, в которых по мимо самого фреймворка и вашего кода нет ничего дополнительно поставленного через composer? Речь не о проектах уровня «Hello world!».
Я о том, что понятно — сам фреймворк быстрый, sf2 курит в сторонке, все дела… Но в реальности все немножко иначе и надеяться на x10 ускорение не приходится.
shoomyst
Понятно, что будет какое-то падение, но я еще раз повторяю, большую часть времени занимает инициализация фреймворка, сторонние либы чаще всего включаются частично в зависимости от страниц. Пусть ускорение будет x5-x8 — вас такой ответ устроит? :D
itcrab
Я не замерял… А раз так — конкретных иксов я не скажу и устроить ваш ответ меня не может без прогнанных тестов. Я говорил лишь о том, что x10 unreal в реальном мире.
shoomyst
Ну так и симфони гибче и масштабнее, там больше кода инициализации, различных проверок.
Все эти цифры приблизительны, но глупо их игнорировать
itcrab
Кто сказал, что я игнорирую их?! Phalcon 2 крут в плане скорости, но сейчас речь не про это. Речь про то, что важно здраво оценивать то, что напишут тестеры и понимать, что синтетика никогда не даст реальных результатов и поэтому важно думать прежде чем выбирать тот или иной фреймворк для вашей задачи. Не более.
imgen
Мы, не используем Composer. Не вижу смысла тянуть в нормальный проект все эти зависимости.
Если Вы пишете код с правилом — «лишь бы было и работало», тогда композер подойдёт и ваш подход подойдёт и sf2 в том числе.
Но в сколько нибудь нагруженном проекте Ваш подход испытает очень большие трудности.
itcrab
Я правильно понимаю вы противник composer way? Каким путем идете вы?
Можете рассказать какие именно огромные трудности испытает нагруженный проект (серьезно интересно)?
По моему composer как раз не для «лишь бы было и работало», а как раз для того, чтобы заюзать удобный интеллектуальный менеджер «пакетов», в котором есть все для дальнейшей жизни проекта (install, upgrade, remove, dependencies).
imgen
Интереcные вопросы, получается короткое интервью, я не являюсь автором проекта и его архитектором по сути, но всё же на некоторые вопросы могу ответить точно.
1. Совершенно верно, мы не используем composer, весь код проекта «изобретается заново», где десятки слоёв абстракций заменяются одним простым и удобным, целевым решением (функцией или классом).
2. У каждого свои трудности, в нашем случае — это средства :) Их всегда — не достаточно, мы не может взять и прыгнуть через голову, приходится идти небольшими шагами.
3. Менеджер пакетов и автоматический контроль зависимостей требует большое количество ресурсов, а мы не любим их тратить впустую :) Приведу пример: мы ищем в композере класс, который позволял бы сделать crop картинки и находится класс, который позволяет делать с изображением всё что угодно, но нам не нужен этот огромный класс, нам нужен только crop с уже известной степенью сжатия и известным путём для файла, а так же алгоритмом «вырезания картинки». Таким образом мы выбрасываем «удобный» класс композера на 1500 строк кода, а так же 10 уровнями абстракции и заменяем его функцией на 150/200 строк.
Zeliret
Т.к. суперкласс в index.php? Насколько «большой» ваш проект? ))
Опыт показывает, что сперва берется функция crop, потом через месяц попросили ввести rotate, потом scale и через пол года вы написали ту самую библиотеку, только криво, на костылях, тогда как та либа покрыта тестами, проверена сообществом 100500 раз и используется в топовых проектах. Пройдено уже ;D
Yeah
Если проект одноразовый, то возможно и так прокатывает. Потом проект приходит к кому-то на support и заказчик слышит волшебную фразу: «Мы щас вам тут все перепишем на %framework_name%»
imgen
Не надо кидаться из крайности в крайность, нет никакого супер index.php :) Большой ли, не знаю что для Вас большой проект, в php файлах насчитал 75000 строк, фреймворка — нет, все базовые классы реализованы в 2-3 тысячах строк.
Rotate не делаем, если понадобится добавить 1-2 строку кода с поворотом угла будет не так уж и сложно, итого получаем 30 строк кода включая комментарии, для древнющего gd :)
Zeliret
Я не хотел кидаться в крайности :) Просто на моем текущем месте работы (когда я пришел туда) четко сказали, что надо писать на статике, типо быстро и просто и т.д. С тех пор прошло уже 4 года, конечно, и сейчас часть того ужасного легаси уже переписана, но часть осталась, как шрам на теле :)
И по опыту опять же, поначалу так и было, что мол проще написать 1 функцию, чем искать либы и т.д. В итоге все это обрастало костылями, никаких абстракций же, лишние усложнения и т.д.
А я по натуре такой программист, который ищет готовые решения всегда. Я велосипед писать буду только если он спасет от падения метеорита )) и то скорей всего сперва загуглю… Поэтому для меня вопрос болезненный ))
iGusev Автор
Если производительность так уж важна, то зачем вообще писать на PHP? Си ваше все. В ином случае получается экономия на спичках.
imgen
еще не пришли к этому, когда возьмут за горло, так оно и будет :)
FractalizeR
Вы имеете ввиду ресурсы компьютера или человеческие ресурсы? Поскольку composer лишь средство для установки PHP библиотек, ваша фраза звучит как «все, что написали другие, по умолчанию раздуто и медленно». Или мне показалось?
Я правильно понимаю, что вы исповедуете NIH философию?
itcrab
Возможно речь про ресурсы шла в разрезе обертки, которую создает composer для autoload'а всех штуковин из vendor. Поправьте если не так.
FractalizeR
Да вот я тоже не очень понял. Не думаю, что обертка composer будет тяжелой. Особенно, если большая часть либ с PSR-4 правилами автозагрузки.
imgen
Имею ввиду ресурсы компьютера.
нет, вы не правильно понимаете, мы используем философию целевого программирования, когда код пишется для какой-то уже известной цели, а не для абстрактных, возможных углов его применения.
Как обычно для хабры, стянулись гуру домашнего программирования и перевернули всё так, как им удобно, считая только их подход правильным, всё будет хорошо, никуда Ваш композер не денется, как писали 90% людей на нём или используя его и PSR-4, так и будут дальше.
Однако — есть проекты, в которых всё это не нужно, не нужно всех под одну гребёнку, каждой задаче должно быть своё решение, впрочем, зачем я это всё объясняю, думаю даже начинать не стоило.
FractalizeR
Почему не стоило? У вас есть позиция, почему бы ее не разъяснить?
Мне непонятно, каким образом отказ от composer экономит ресурсы компьютера. Непонятно также, каким образом в разработке помогает NIH-принцип.
И мне бы хотелось понять вашу точку зрения.
itcrab
Вам везет)) Серьезно!
Мой опыт и опыт всех моих знакомых разработчиков показывает, что обычно у нас нет времени на трюки с выпилкой только нужного функционала из подключаемых либ. Я о том, что скажем в проекте с 20-30 зависимостями (мы понимаем, что это не предел для долго играющих проектов) из composer у нас просто физически нет времени на описанные выше действия.
Часто приходится быстро находить решения для задач, чтобы клиент остался доволен и проект завершился во время. Конечно, это вопрос менеджмента на проекте и возможно здесь есть над чем задуматься. Хотя опять же ваш подход как я думаю в теории должен сильно увеличивать сроки, даже с учетом, что все ходовые штуки вы уже давно выпилили и юзаете от проекта к проекту. Или нет?
imgen
Да, сроки большие, всё связано с тем, что это не аутсорсинг проект, задачи решаются постепенно по мере их необходимости, код пишется целевой максимально короткие сроки, главный упор на бекенде — бытсродействие, на фронтенде — функционал.
А для аутсорсинг проектов конечно же нет смысла изобретать что-то, можно брать всё готовое, лишь бы работало)))
DjOnline
Для этого надо исключить инициализацию при каждом запросе (отказаться от php always die) и использовать подход одноразовой инициализации как в node-js: phpDaemon, reactphp, prefork.
iGusev Автор
Я просто оставлю это здесь
github.com/kenjis/php-framework-benchmark
SerJook
Хотелось бы увидеть сравнение скажем с Django.
namespace
Нет-нет, значительно более хотелось бы увидеть сравнении с Flask!
virtustilus
Как часто заказывают hello world проекты? почему?
В большом проекте будут разного вида кэши (не видел пока ни одного крупного проекта без кэширования). И symfony2 выдаст уже совсем другие результаты.
А если к ней прикрутить reactphp (по умолчанию никаких утечек памяти в симфе — проверяли), то можно будет уже и на верхних строках оказаться.
Интересно, если бы кто такой тест сделал, у кого есть время и скиллы потестировать?
Zhuravljov
Тоже самое можно сказать про любой другой нормальный фреймворк.
virtustilus
я о том же, просто на примере php, т.к. работаю постоянно с ней
seyfer
Это если читстый фреймворк запускать — будет такой показатель.
Если написать своего кода на PHP сверху да подключить несколько компонентов Symfony или Zend для решения задач и все, скорости уровнялись.
Для микро фреймворков то же самое.
xamin
Zephir, судя по документации настолько похож php, что любой php-программист разберется в нем очень быстро, в то время как научиться писать расширения на Си намного сложнее, особенно для людей плохо знающих Си
KlonD90
В C норм, а вот в ту штуку на которой пишутся extension прям это кровь из глаз какое-то :(
KReal
Да ладно вам, даже на сишарп похоже)