Это перевод статьи Ruby (on Rails) ecosystem bittersweet or "we like to hate PHP", написанной 30 мая 2016, т.е. совсем недавно. Я полностью согласен с её автором, и сам давно горел желанием написать что-то подобное в последнее время, но у меня не так много опыта с Ruby, поэтому моя писанина не была бы настолько объективна, как писанина человека, который этот опыт имеет, и имеет его в хорошем количестве. А тут на тебе: всё в одном месте уже собрано, и мысли прямо один в один как у меня. Грех не перевести на русский. Также, статья вообще очень хороша как небольшой набор объективного и беспристрастного анализа двух языков современной веб-разработки. В общем, далее — перевод слов автора.
многобукв; нечитал;
В этой статье я рассказываю о некоторых фактах и персональном опыте для того чтобы доказать, что PHP в данный момент живее, конкурентоспособнее, а также имеет менее связанную экосистему, чем Ruby. Я говорю о Производительности, Синтаксисе и Аспектах кодинга, Сообществе и Инструментарии разработчика.
Если у вас есть желание пропустить воду — проскрольте до заголовка "Основная часть начинается здесь..." :) Но мне нужно это сказать...
Что? Очередная анти-RoR проповедь?
Ну да, я начал собирать материал для этого поста больше шести месяцев назад, и я знаю о всех дискуссиях, которые ведутся на тему "за" и "против" RoR в последние недели. Основные обсуждаемые нынче статьи — это Моё время с Rails закончилось и Rails выйграл: Слон в Комнате. Я определённо не настолько опытен в RoR, чтобы сказать что-нибудь новое на тему архитектуры, что ещё не сказал кто-то другой. Я только хочу поспорить за лидерство Rails в веб-разработке.
[PHP]… фрагментированные, независимые и изолированные сообщества… Это один большой океан разрозненных островов.
Сказал как-то AkitaOnRails, и всё это правда с одной стороны, и ложь — с другой. Дорогие рубисты, позвольте мне продемонстрировать вам вашего ближайшего конкурента: PHP. И не существует чего-то особенного в Ruby для типичного Basecamp приложения, чего мы не можем найти в PHP.
Эволюция моего видения...
Я пришёл в мир Ruby только около полутора лет назад, после более пяти лет разработки на PHP. Я испытывал много мучений. Это не лёгкая миграция и адаптация. Жизнь сложилась так, что я решил с нуля создать команду разработчиков Ruby (on Rails) в MobiDev. С того момента я замешан в самообучении и ускорении развития своих Ruby джуниоров и миддлов.
Очень скоро я понял одну вещь: все эти хипстерские и cool-kids образы из мира RoR были немного преувеличены. Сегодня, RoR не предлагает ничего особенно более лучшего, чем любой средний PHP фреймворк, разве что за исключением фоновых задач из коробки.
Что ещё хуже: он стимулирует некоторые подходы к разработке, которые "считаются вредными" © даже в PHP. Тут поощряются нарушение принципа единственной обязанности и CQRS прямо самим фреймворком. И, если честно, большое RoR приложение является тотальной магией из-за вездесущих манки-патчей неявного включения во всё подряд.
Просто подумайте об одном примере нарушения принципа единственной обязанности...
"Разве мы не перестали работать с PHP по этой причине?"
Прости Ник, я цитирую твою книгу, и не согласен с данным утверждением. Я вижу, что огромное количество Ruby разработчиков любят пошпынять PHP. Большинство из них не видели ни одной строки реального PHP кода, но "мой друг сказал мне… что это кошмар". Или они видели WordPress — самый популярный и самый уродливый с точки зрения архитектуры PHP код, который когда-либо был написан.
Я хочу заявить о том, что это некорректное мышление для 2016 года, и PHP сообщество имеет множество таких вещей, которые отсутствуют в сообществе Ruby на данный момент.
Piotr Solnica
В мире Ruby фреймворк следующего поколения никогда не появится... http://disq.us/9qybwk
И, простите, но перед тем как перейти непосредственно к PHP, я должен оставить здесь два риторических для Ruby параграфа...
Это как домашнее насилие
Когда я думаю о Rails и о реакции большинства рубистов на предложение "думать вне RoR", это напоминает мне поток сознания жертвы бытового насилия. И что-то вроде Стокгольмского Синдрома зависимых от RoR.
Вообразите эту печальную, но правдивую историю. "Золушка" живёт в холодном, страшном и адски сложном мире. Она влюбилась в Очаровательного Принца. Он просто потрясающий: понимает её с первых слов, делает её жизнь такой яркой, обещает всегда её любить и делать для неё всё, что она попросит...
Они поженились и переехали в его замок. И её жизнь немного изменилась...
После множества прожитых совместно лет, она уже не может сделать и шага без Его разрешения, Он даже мог побить её, когда она пыталась. Она должна докладывать о каждом своём шаге и подстраивать всё под Его течение жизни. Она уже давно забыла о том, как можно жить без его чрезмерной опеки и помощи со стороны слуг. Все люди, которых она знает и с которыми она общается — такие же жёны домашних тиранов. И всё чаще и чаще она слышала от её "очарования": "Даже не думай оставить меня! Никто не нуждается в тебе, кроме меня! Ты не можешь ничего сделать в одиночку!"...
Замкнутый круг спроса
Ответ: ничего. Нет ничего запрограммированного в Ruby для того чтобы остановить тебя при использовании своих острых ножей для того, чтобы разорвать отношения с разумом. Мы претворяем в жизнь такие хорошие соглашения путём подталкивания и через обучение. Не через запрет острых ножей и не через призывы использовать ложки для нарезания помидоров.
DHH, "Provide sharp knives"
Образование. Rails действительно учат нас?
Разработчики начинают использовать Rails. Обучаются только рельсам. Не могут сделать шага без них. Не могут отличить, что является чистым Ruby, а что является рельсовым манки-патчем. Они не видят чего-то лучше этого, да и не хотят ничего лучше. Не могут сделать даже крошечный SQL запрос без ActiveRecord. Производительность? Кто об этом заботится? Клиенты попадают на Rails-маркетинг и "широкое сообщество разработчиков". Они требуют, чтобы проекты писались на Rails. Разработчики используют Rails потому что это так легко (не просто!), ну и Клиенты же хотят Rails (спрос рождает предложение).
Когда вы подумаете о том, куда пойти после Rails — вы поймёте, что идти, в общем-то, некуда. Клиенты не желают писать не-Rails приложения, потому что они "скорее всего не нашли бы не-Rails разработчиков". То же самое с разработчиками: они боятся оставить Rails, потому что "они не смогут найти не-Rails работу". Порочный круг. И уже нет разницы, "предложение рождает спрос", или же наоборот.
Такой проблемы не существует в мире PHP. Клиенты почти никогда не требуют какой-то конкретный фреймворк. Разработчики, в свою очередь, имеют возможность свободно выбрать тот инструмент, который они знают, и который лучше всего подходит к требованиям. Да, тут есть много Rails-подобных фреймворков, но также здесь имеется и набор фреймворков с отличной философией.
?( •??•??) Основная часть начинается здесь...
Эволюция и Производительность
В 2005-м PHP зарелизил версию 5.0, и ООП-подходы стали возможными для реализации (с момента релиза версии 3.0, там были очень ограниченные возможности ООП). Безусловно, RoR здесь является правопреёмником. И PHP не мог показать нечто конкурентоспособное в течении долгого времени.
Но, начиная с 2012, PHP получил массивный толчок вперёд вместе с версией 5.4, HipHop VM от Фейсбука и расширением экосистемы. Сегодня, с версией 7.0 и HackLang от Фейсбука, PHP имеет увеличенную вдвое производительность и низкое потребление памяти. Это определённо не медленнее Ruby 2.x.
Самое большое преимущество PHP приложений заключается в том, что скорость работы кода не зависит от Dev / Production окружения. Он не требует перезагрузки классов (т.к. каждый новый запрос использует актуальный код). Только расширение отладки даёт некоторый штраф. Но Production окружение не выкинет вам какое-то неожиданное поведение, так как обычно нет никакой разницы где запускается ваш код.
Будущее PHP ясно, потому что он имеет корпорации, стоящие за ним — Zend, Facebook, и так далее. Они постоянно работают над языком для того чтобы сделать его ещё лучше и быстрее.
Что насчёт Ruby? Множество туманных реализаций с туманный перспективами. (прим. переводчика — есть ещё такая вещь как Elixir, который тоже во многом является приёмником Ruby)
Сообщество
Не смотря на то, что корпорации вкладываются в развитие PHP, сам по себе он имеет реальное сообщество — PHP FIG (Framework Interop Group)
Идея группы заключается в общении представителей проектов для обсуждения общих проблем между разными проектами и совместного поиска путей решения. Наша основная аудитория — это мы сами, но мы очень хорошо понимаем, что остальная часть PHP сообщества наблюдает за нами. Если другие желают принять то, что мы делаем, они могут это сделать, но это не является целью. Никто в группе не желает указывать вам, как программисту, как вам следует разрабатывать своё приложение.
И эти парни из множества PHP проектов работают вместе (да, иногда они очень громко ссорились) и предлагают хорошо продуманные Стандарты Рекомендаций PHP. И сообщество реально принимает их через какое-то время.
Спасибо PHP FIG за то, что мы теперь имеем такие важные вещи, как Стандарты Кодинга и Стандарт Автозагрузки по Неймспейсам. Трудно переоценить, насколько важны эти вещи для современного PHP. Это действительно даёт нам возможность совмещать различные проекты и библиотеки в одной безконфликтной кодовой базе.
Я честно не вижу ничего подобного в Ruby, есть лишь Rails-диктатура.
Пакеты
Да, Bundler и Gems были удивительны для Ruby, и ручное копирование-вставка в PHP была ужасной. Начиная с 2012, PHP получил Composer, спасибо стандартам PHP FIG. Его цель в управлении пакетными зависимостями и в автозагрузке кода приложения.
Самая большая разница в том, что зависимости PHP хранятся на уровне проекта (каждый проект скачивает свой набор зависимостей), и по этой причине не может возникнуть каких-то коллизий между проектами.
Код автоматически загружается на основе Неймспейсов. И на практике это работает лучше, чем Constant Autoload в Rails с Ruby модулями. В PHP все пакеты имеют уникальное имя поставщика в Неймспейсе, и это позволяет очень легко отследить, какой код был загружен. Я реально имею массу проблем с этим в Rails, и не имею никаких проблем на стороне PHP.
PHP имеет Лигу Выдающихся Пакетов — группу разработчиков, которые объединились вместе, чтобы построить прочные, хорошо проверенные PHP пакеты с использованием современных стандартов программирования. Они имеют множество высококачественных независимых пакетов для Роутинга, Внедрения Зависимостей, Событий, Команд, Авторизации, Манипуляцией временем и многого другого. И нет ни одного ограничения для того, чтобы вы использовали эти прекрасные библиотеки в любом PHP фреймворке. Вы даже можете совместить их и создать свой собственный фреймворк!
Другой прекрасный пример — Aura for PHP — это полнофункциональный фреймворк, но состоящий из слабо связанных компонентов, которые вы можете использовать самостоятельно, или комбинировать из них то, что вам нужно.
[PHP]… фрагментированные, независимые и изолированные сообщества… Это один большой океан разрозненных островов.
Хм… Быть реюзабельным, изолированным и слабо связанным — это не значит быть "фрагментированным" или "разрозненным", и Магический Монолит — это не единственный архитектурный вариант!
Манки патчинг
Следует ли мне рассказывать о том, что PHP не имеет возможности манки-патчинга в своей основе? И что пакеты не сталкиваются друг с другом, когда какой-то манки-патч уже создал подобный метод в объекте. Да, это является ограничением PHP, вы не сможете делать много всякой магии как в Ruby, но мне правда лучше живётся без этих "острых ножей", и лучше думать о правильном OOП-дизайне, чем о заплатках.
Большое преимущество заключается в том, что утилиты предоставляются в явном виде. Да, есть их некоторое количество, и большинство фреймворков поддерживают свои собственные. Но любой фреймворк подталкивает что-то в ваше приложение.
Но подождите! 5.minutes.ago — это же так прикольно!На самом деле не очень. Очень хорошая мотивация для этого даётся realntl на Reddit (читать полный текст)
Это в своей основе плохая форма: вставлять магические цифры в коде. Предпочтительнее использовать константы, и из-за того, что вы используете Integer#minutes от ActiveSupport, вы скорее всего закончите кодом вроде этого:class Foo
MINUTES = 5
def bar
MINUTES.minutes.ago
end
endОбратите внимание на избыточность, которая содержится в указанном мною моменте в то время когда я назначаю значение переменной. Это означает, что вся польза отInteger#minutesбудет только в ситуациях, когда элементарное значение вкладывается непосредственно в код — что на самом деле является наименее желательным местом, в которое было бы хорошо поместить это элементарное значение. Другой недостатокInteger#minutes(и, естественно, дней/неделей) это то, что он в основном используются для работы с временными отрезками, связанными с другой точкой времени — как правило, "сейчас". В этих ситуациях у вас возникнет потребность в указании источника времени, чтобы поведение можно было бы корректно контролировать во время тестов. Без возможности управления временем, вам придётся использовать timecop style gem для решения этой проблемы. Отныне всё, над чем вы работаете, стало более сложным и менее явным. Это предсказуемо: неявный код создаёт проблемы, а потом в качестве решения предлагается ещё более неявный код.
Так каков же правильный путь для того чтобы сделать 5.minutes.ago в Ruby? Использовать библиотеку Time и сделать это через TimeMath.minutes.decrease(Time.now, 5).
В Rails манки-патчи добавляют в стремлении к красоте кода, чтобы скрыть проблемы "жирных контроллеров". Rails пытается сделать код Контроллера маленьким через некоторые кусочки кода вроде Array#second_to_last, Array#third_to_last или ArrayInquirer. Простите, но это уже выглядит смешным.
(Уродливый) Синтаксис
Ruby имеет определённо больше возможностей для написания "хорошего" кода. PHP никогда не будет даже близок. Потому что он требует явного указания $this, а также точки с запятой и скобок :) И, конечно, это лишь вопрос времени, чтобы привыкнуть к этому. Ну а с хорошей IDE это вовсе перестаёт быть проблемой в написании кода и читабельности.
Ruby имеет возможность определить классные предикатные методы вроде admin?/access?, в PHP вы не можете использовать символ ? в названии метода, и предикаты в PHP обычно решаются через называние методов как isAdmin/hasAccess.
PHP имеет опциональный(!) Контроль типа. И поверьте мне — когда вы привыкнете к этому, вы поймёте, какая это удобная функция. Если у вас есть стремление сделать свой код более строгим, вы всегда можете сделать это через нативные языковые конструкции. Это позволяет добавить натуральную поддержку реализации контейнеров Внедрения Зависимостей, а также получить классное автодополнение в IDE.
DSL
PHP не имеет DSL, по крайней мере такой, какой существует в Ruby.
DSL хорош в тех ситуациях, когда он используется где-нибудь в Vagrantfile. Но не очень хорошо, когда его использованием злоупотребляют без хороших причин, стремление писать всё в DSL ИМХО некорректно. Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL. Всё, что делается через DSL, должно делаться и без него. Таким образом мы согласуемся с принципов "Простое легко, сложное возможно".
Метапрограммирование
Ruby имеет непревзойдённую возможность к динамической композиции во время выполнения. Разработчик имеет возможность переопределить элементы Класса (методы, и так далее). Господи, как я это ненавижу! :D Потому что я никогда не знаю "где найти это ***ое определение метода". Но это "острый нож", и в хороших руках разработчик может делать великие вещи.
В PHP нет такой силы. Единственная магия, которую вы можете делать — это использовать "магические методы" типа __get для получения и возвращения отсутствующего свойства или __call для реакции на отсутствующий метод. Есть некоторый набор подобных методов. И, тем не менее, меньшее количество магических возможностей, которое у вас имеется, упрощает анализ кода.
Фреймворки
Наконец, мы подошли к главному пункту. Мир PHP имеет полноценный конкурентоспособный мир фреймворков. Это именно те парни, которые формируют PHP FIG и принимают взаимные соглашения. И там нет единогласного лидера. В течении более семи лет между ними существует большая конкуренция. И люди пишут любые виды приложений на всех этих инструментах.
Полнофункциональные фреймворки:
- Laravel 5 — один из самых трендовых фреймворков в последние 2-3 года, с большим количеством DDD архитектурных подходов.
- Symfony 3 — считается одним из самых Enterprise-подобных фреймворков, имеет слабо связанные компоненты и хранит код приложения изолированным от фреймворка.
- Yii 2 — имхо, один из самых "рельсовых" фреймворков, довольно твёрдый и связанный в пользу скорости разработки.
- Phalcon — совершенно уникальный PHP фреймворк, работающий как C-расширение, имеющий самый высокий показатель количества запросов в секунду.
- Zend 2 — один из самых старых фреймворков, созданный компанией Zend, разработчиками PHP, но, тем не менее, имеющий очень низкое влияние на рынке PHP кадров.
Большинство данных фреймворков изначально были вдохновлены Rails или каким-то другим PHP кадром (который, в свою очередь, был вдохновлён Rails :)). И первая версия Yii фреймворка была также очень устойчива к изменениям в соглашениях. Но, как вы видите, все они уже были пересмотрены и переписаны по несколько раз. И в множестве случаев это касалось больших изменений в архитектурном мышлении.
PHP получил "второе" поколение фреймворков ещё пару лет назад! Они пытаются управлять слабо связанными компонентами и сущностями. Они уважают системы пакетов и большинство из них требуют лишь небольшую обёртку (а иногда и вовсе никакой обёртки) для пакета, чтобы он стал чувствовать себя внутри фреймворка "как дома".
Помимо прочего, существует также параллельная вселенная мини-фреймворков, некоторые из которых являются урезанными версиями "старших братьев" (Lumen < Laravel, Silex < Symfony). Но даже они предоставляют прочные и отработанные механизмы роутинга и внедрения зависимостей для создания такой бизнес-логики, которая вам может потребоваться.
Что мы имеем в мире Ruby? Ответ прост: Rails. И ещё Sinatra, мини-фреймворк.
Молитесь Всевышнему за Hanami.
Архитектура
К сожалению, в PHP я не знаю разобранного архитектурного фреймворка (такого как Trailblazer в Ruby). Каждый фреймворк пытается предложить свой собственный архитектурный подход. К примеру, Laravel предлагает DI, RequestForms, Events и Command/Handler, Entity/Repository, и так далее.
Большинство фреймворков в PHP поощряют разделение компонентов и внедрение зависимостей, но, к несчастью, как и в Rails — никто не учил их хорошим и правильным подходам. Всё это по большей части зависит от самого разработчика.
UPD
Я нашёл пример архитектурного фреймворка в PHP: Broadway
Broadway является проектом для создания инфраструктуры и помощников в тестировании для создания CQRS или событийно-ориентированных приложений. Broadway старается из-за всех сил, чтобы не встать у вас на пути. Проект содержит несколько слабо связанных компонентов, которые могут быть использованы вместе, чтобы обеспечить полный опыт CQRS \ ES.
ORM / DAO / Data Access
Это начинается с ActiveRecord в виде ORM'ов, но быстро оценивается в подход с Entity/Repository. Также существует множество конкурентов для Yii ActiveRecord со слоем DAO (кстати, в них имеется поддержка нескольких БД, запросов между несколькими БД, даже между реляционными и NoSQL), Doctrine, Eloquent, PropelORM, и так далее.
В Rails мы имеем ActiveRecord — и весь мир вращается вокруг него. Hanami имеет свой DataMapper-подход. И ещё есть библиотека Sequel.
Интересный факт заключается в том, что создатель DataMapper в Ruby стал NoORM-персоной и теперь рассматривает все ORM-подходы не стоящими усилий.
Статический контент
Rails имеет качественный инструмент Sprockets, которая была магически клёвой в ранние дни: они может компилировать и комбинировать JS, CSS, SASS, LESS, и так далее. Можете расслабиться и забыть про него.
PHP фреймворки изначально не имели ничего подобного. В PHP не запускается свой сервер и наблюдатель изменений. Rails имел превосходство.
Но мир JS/CSS изменился. Так быстро, что Sprockets просто не успевает приспособиться (это очень медленный процесс в Dev окружении, assests:precompiletask нужна вечность при деплое, и он не поддерживает все последние JS пре-комилеры). Вся работа по обработке JS/CSS нынче выполняется на стороне утилит Node.js вроде Webpack/Babel. Это практически промышленный стандарт. И Rails теперь потерял своё преимущество.
Сегодня каждый может взять Node.js + WebPack и использовать все современные ES6 + SASS + JS фрейморки + Горячую перезагрузку, не смотря на язык и фреймворк, который он использует. Я делаю это и с PHP, и с Rails. Мне не нужны специфичные для Rails скиллы, когда я могу использовать общие навыки.
Фоновые задачи и очереди
Одна вещь, которая отсутствует в PHP — это фоновые задачи. В силу того, что его процессы не предназначены для долгой жизни. Есть несколько подходов для подключения PHP демонов, но PHP требует некоторую помощь здесь — супервизоры, следящие за процессами + бекенд для очереди задач (Redis, Beanstalkd, и так далее).
У Ruby здесь имеется гораздо больше собственных инструментов типа DelayedJob, Sidekiq, и так далее. И это является удивительным, когда вы откладываете операции "бесплатно", без всякой дополнительной мозговой деятельности — вы можете сделать более лучший старт на начале. Но в конечном счёте масштабируемые очереди Ruby используются вместе с Redis или чем-то подобным.
Поддержка IDE и авто-завершение кода
Изначально мне было интересно, по какой причине большинство Ruby разработчиков не используют большие IDE, и вместо этого сидят в Sublime, и т.д. Впоследствии я понял, что даже такие классные IDE как RubyMine не дают вам практически ничего в плане автодополнения кода для Ruby. Из-за его динамической природы. И это до сих пор меня расстраивает.
В PHP, не смотря на то, что это тоже динамический скриптовый язык, автодополнение работает намного лучше. И он имеет широкий стандарт PHPDoc, который позволяет аннотировать ваш код, чтобы дать почти 100% корректное автодополнение даже для динамических фабрик. Фреймворки и библиотеки полностью аннотированы, это правило этикета в PHP: аннотация исходных кодов. И мне очень не хватает этого в Ruby.
Тесты
Ruby имеет выдающиеся возможности тестирования благодаря своей способности вновь открывать классы и создавать нативные заглушки. Это действительно не требует использования внедрения зависимостей для изменения сложного поведения кода во время тестов. Вместе с RSpec, Minitest и Cucumber вы можете создавать любые типы тестов: Юнит, Интеграционные и BDD.
PHP также имеет набор инструментов для тестирования — основным является PHPUnit. Он предоставляет прочную основу для различных проверок и заглушек. Фреймворк Codeception предоставляет BDD-стиль Юнит и Интеграционных тестов. Также имеются подходы, копирующие Cucumber (такие как Behat), но я думаю, что это едва используется в PHP. Единственным ограничением является лишь то, что в Юнит тестах вы можете использовать грязные методы и действительно нуждаетесь в обдумывании внедрения зависимостей или создании заглушек для точек входа ваших классов.
Да, TDD не мёртв, вам просто нужно продумать архитектуру своего кода.
Заключение
И нет никакого заключения.
В любом случае, я не призываю вас оставить Ruby и начать работать на PHP!
Я просто надеюсь на то, что данный пост сможет убедить кого-то в том, что Ruby on Rails является не таким уж большим Слоном в Большой Комнате Разработки Веб-Приложений. В течении долгого времени люди из "параллельной PHP вселенной" делают великие продукты и хорошо проводят время вместе с инструментами, которые совсем не хуже того, что существует в мире Ruby. Если вы не можете смотреть так широко — вы знаете, кто в этом виноват!
Обновление от 2016.06.01
На основании на комментариев здесь и на Reddit, я хочу собрать основные поправки и жалобы.
Это не про Ruby On Rails, а про плюрализм и агностицизм
Я не собирался обсуждать недостатки архитектуры Rails в данной статье. Это не основная цель. Я стремлюсь показать, как сильно это влияет на всю экосистему Ruby. И как отличается ситуация в мире PHP с плюрализмом фреймворков и агностицизмом библиотек.
Пост посвящён в целом экосистемам, а не каким-то конкретным фреймворкам или отдельным аспектам языка (вроде манки патчинга).
5.minutes.ago
Окей, просто остановим это :) Мы всегда говорим о разных вещах. Одна сторона пытается убедить в "красоте кода", а другая винит его за "внутреннее состояние". И пока мы будем обсуждать вопрос 5.minutes.ago в таком ракурсе — это будет бесполезно.
Laravel
Любопытно, что он жалуется на RoR и при этом приводит в пример Laravel, когда Laravel — это практически RoR в мире PHP
В определениях функций RoR и Laravel разделяют не так много, но ведь в терминах философии они разделяют намного больше?
Это на самом деле не так важно, насколько Laravel и Rails разделяют, и насколько авторитетен Taylor Otwell. Что более важно, и что я старался подчеркнуть — это то, что Laravel не вредит экосистеме PHP, вне зависимости от того, что происходит в экосистеме Laravel (и это нормально для PHP, так как язык поощряет писать реюзабельные решения и просто делать небольшие обёртки для интеграции с фреймворками, а не наоборот). Что касается Rails — то они делают больно и влияют на всю экосистему Ruby.
Laravel и DDD, да, я сделал слишком громкое заявление, я просто хотел подчеркнуть, что не смотря на то, что он был вдохновлён Rails, он имеет множество передовых архитектурных особенностей из коробки: внедрение зависимостей, формы, командная шина, и так далее.
Behat / Cucumber
Я удивлён, что он "почти не используется". Я люблю Behat
Потому что это не утилита для тестов :) Это инструмент коммуникации, который позволяет вам преодолеть разрыв и избежать недоразумений между вашим бизнесом и вашей технической командой.
Я сильно удивлён тем, сколько людей подняли руки в пользу Behat / Cucumber. И простите, кажется, мои слова могли выглядеть резкими. Я всегда рассматривал Behat как инструмент для тестирования. Я имею очень упрямое видение автоматизированного тестирования, и рассматривание подхода Огурца не самый простой путь (без разницы, реализация на PHP или Ruby). Тесты это очень чувствительные вещи, и я стараюсь держать их ближе к нативному коду, насколько это возможно (с простой отладкой и автодополнением), т.е. я использую PHUnit + Codeception в PHP или Minitest+Capybara в Ruby.
Комментарии (203)
printercu
28.07.2016 07:19Откуда такой кипиш?! Раз в месяц кто-то новый пишет, как ему не нравятся рельсы. Ну не нравятся — хорошо. "Но, пожалуйста, не доставайте и не размахивайте им на людях."
saggid
28.07.2016 07:38+23Ответная реакция на эти регулярные выпады в сторону PHP, мсье) Пыха нынче уже не тот, может кое-чем и ответить.
printercu
28.07.2016 12:21+8Я особо не слежу, но мне не попадается уже пару лет про пхп ничего нового такого. Про го — помню, про ноду — помню, про скалу — тоже. Про пхп — нет, уже все давно написано. Да и выпадов на пхп, по-моему, меньше стало.
taliban
28.07.2016 10:35+8Откуда такой кипиш?! Раз в месяц кто-то новый пишет что ему не нравится такая статья. Ну не нравится — хорошо. «Но, пожалуйста, не доставайте и не размахивайте им на людях.»
varnav
28.07.2016 08:19-9Для меня как админа смущает многошаговый деплой RoR приложения по сравнению с PHP, где надо просто скопировать файлы.
VolCh
28.07.2016 08:44+2Вы, наверное, мало встречались с современными PHP-приложениями. Навскидку при деплое обычного веб-приложения (в предположении, что среда исполнения развёрнута) надо:
0. Включить maintenance mode
1. Залить файлы
2. Настроить конфиги
3. Установить зависимости (composer install)
4. Прогреть кэш генерируемых php-файлов
5. Прогнать миграции базы данных
6. Установить зависимости для фронта (часто npm install)
7. Сбилдтить всё для фронта (webpack например)
8. Включить production mode
Gugic
28.07.2016 08:45+2Все это можно сложить в один gulp build:prod
VolCh
28.07.2016 08:57+6Или команду консоли симфони, или баш-сценарий, или плэйбук ансибл, или рецепт шефа — суть не меняется, шаги остаются
Gugic
28.07.2016 09:04+1Но это уже не будет касаться админа.
Ну и да, в список еще клиетнские зависимости надо добавить (которые через bower install) и что-то, что из разберет по нужным папкам.VolCh
28.07.2016 09:41+1А кого, простите? Кто должен писать сценарии развёртывания? Разработчик должен их описать, а вот написать в общем и в целом не его обязанность и, главное, не его зона ответственности. Другое дело, что админы часто недостаточно компетентны, а девопсы отсутствуют как класс, и приходится писать сценарии по принципу «кто если не я», просто для того, чтобы самому ручками всё не деплоить, рискуя пропустить какой-то шаг.
6. Установить зависимости для фронта (часто npm install)
7. Сбилдтить всё для фронта (webpack например)Gugic
28.07.2016 12:56Тут где-то должен быть водораздел. Разработчик должен написать сборку (точно шаги 6, 7 и вполне вероятно шаги 3, 4, 5 из вашего списка), с учетом всех нюансов работы в dev/prod/stage режимов, девопс должен написать все остальное и интегрировать в CI систему.
Через npm как правило ставят зависимости именно для сборки фронтенда. Сторонние библиотеки, которые используются непосредственно в работе клиента (типа jQuery или Angular) подтягиваются через bower как правило.
Fesor
31.07.2016 19:54подтягиваются через bower как правило.
это уже давно не так, по сути с тех пор как появились бандлеры намного удобнее использовать npm или модный jspm. Bower полезен только для очень примитивных схем сборки.
VolCh
01.08.2016 07:58Всё зависит от квалификации как девопса, так и разработчика, по-моему. «Чистый» разработчик может просто не знать какие окружения будут в dev/prod/stage режимах. Я вот посылаю к админам фронтендеров и дизайнеров, когда они хотят развернуть проект локально под виндой. Я кое-как автоматизировал развёртывание в прод и стейдж с предположением, что на сервере стоит не просто та же ось, но и тот же дистрибутив той же версии, что и у меня на ноуте, а всё остальное не моё, как разработчика, дело, по-моему. А во многом и так чужую работу делал.
LastDragon
28.07.2016 09:15+3По своему небольшому опыту взаимодействия с рельсами (а конкретно периодическое обновление redmine) могу сказать что почти любой проект на PHP гораздо легче поднять чем на рельсах — последний раз особенно доставил переезд на centos 7 — вроде и окружение очень похожее, но все равно пришлось помучиться несколько часов — bundler отказался грузить зависимости из-за конфликтов/ошибок, а гугл как обычно оказался пуст :( И это реально проблема — любую нестандартную ошибку практически невозможно нагуглить, redmine у меня где-то с 2010 наверное и я бы не сказал что стало сильно лучше (обновляю раз в год/два), разве что bundler появился, до него всё еще печальнее было...
drakmail
28.07.2016 09:34+1У Redmine, на мой взгляд, не самая лучшая архитектура. Ну и обычно rails приложения деплоят одной командой Capistrano.
VolCh
28.07.2016 09:42+2Который нередко используется и для деплоя php-приложений. По крайней мере до появления докеров и ансиблей.
imgen
28.07.2016 11:35и после их появления capistrano смотрится не хуже, мы до сих пор используем capistrano и только рады.
VolCh
28.07.2016 12:20+1Для capistrano, как правило, нужен уже подготовленный сервер, сценарии с шагами типа «apt-get install php» писать и поддерживать тяжело. Готовить его удобно с помощью того же ансибля или аналогов, и он же хорошо справляется с задачами деплоя — зачем плодить сущности? Сейчас капистрано остался только на старых проектах, переводить специально смысла нет, но нет и смысла начинать новые симфони/сайлекс/… проекты с капистрано.
grossws
28.07.2016 22:25Мы деплоили через него статику и шаблоны для java-приложений, довольно универсальная штука, в общем-то. С сильным перекосом в сторону ruby-мира (поддержка того же
rvmи рельсов), но это естественно.
BoBRoID
28.07.2016 18:49мой алгоритм развёртывания php приложения на yii2:
0. maintenance mode on
1. git pull (svn export)
2. composer update
3. ./yii migrate
4. maintenance mode off
зачастую это происходит по хуку с github'а при апдейте master'а, и выполняется автоматизировано
p.s. если у кого проект не на vcs, то шаг 1 выглядит как выгрузка файлов по ftpbohdan4ik
28.07.2016 21:40+5Для чего вы делаете `composer update`? При развёртывании нужно устанавливать ровно те версии зависимостей, с которыми разрабатывалось и тестировалось приложение, а они хранятся в composer.lock, который `update` перезапишет с новыми версиями. Нужно использовать `composer install` и хранить composer.lock в системе контроля версий.
BoBRoID
29.07.2016 10:45я, обычно, проверяю локально, чтобы приложение было совместимо со всеми последними версиями зависимостей, и только потом деплою
ваше утверждение тоже верно, так как если я заброшу поддержку приложения, и вдруг обновятся зависимости, то всё упадёт, но я говорю про приложение, над которым ещё идёт (или в перспективе будет идти) разработка, и которое не упадёт в паблик для всех
я просто не знаю: вдруг 90% разработчиков реально разрабатывают opensource для всех, тогда да, я не прав, но в большинстве случаев при обновлении зависимостей происходит исправление каких-то глюков этих самых зависимостейmayorovp
29.07.2016 10:55+4Вот после локальной проверки и надо фиксировать
composer.lockв репозитории, а при деплое — использоватьcomposer install. В противном случае можно нарваться на выход новой версии в процессе деплоя.
Kane
28.07.2016 08:49Из каких шагов состоит деплой RoR и PHP приложений?
varnav
28.07.2016 11:08-4Деплой приложения на RoR, согласно этой статье, из 20 с лишним шагов.
Деплой приложения на PHP, ну например популярного Wordpress, согласно этой статье, из 5 шагов.
sl_bug
28.07.2016 11:10+4cap production deploy
Один шаг. Всё остальное это настройка capistrano и подготовка окружения к первому деплою.varnav
28.07.2016 11:16+2С таким подходом можно вообще любую задачу свести к одной команде. Типа:
— Как развернуть информационную систему X, состоящую из 43 хостов, в т.ч. серверы приложений, кэша, веб-серверы, БД серверы, серверы мониторинга, обработки AMPQ, и так далее?
— Одной командой, ansible-playbook deploy_x_system.ymlsl_bug
28.07.2016 11:22+2Ну тогда и в пхп нужно считать правильно, и не по вордпрессу. Деплой первого попавшегося приложение на yii2 + angular в нашей компании, судя по дженкинсу, состоит из 21-го шага.
Fedcomp
28.07.2016 11:14+1Что в php приложении что в типичном rails приложении (т.к rails практически монополист среди руби фреймворков) вы будете использовать систему деплоя, а это зачастую одна команда. Я уже не говорю о том что зачастую деплоить вообще должен CI из мастера, например.
varnav
28.07.2016 11:18+1Разумеется. Но там выше верно подметили: Все это можно сложить в один gulp build:prod Или команду консоли симфони, или баш-сценарий, или плэйбук ансибл, или рецепт шефа — суть не меняется, шаги остаются
sumanai
28.07.2016 09:11+10Ruby имеет возможность определить классные предикатные методы вроде admin?/access?, в PHP вы не можете использовать символ? в названии метода,
Юникод позволяет делать страшные вещи на PHP.
<?php define ('Да', true); define ('Нет', false); function лол?($лольность = Нет) { if ($лольность) { echo 'Лол!'; } else { echo 'Не лол ('; } } лол?(Да);
Не повторяйте это в реальных проектах!Ch4r1k
28.07.2016 11:56+5Юникод позволяет делать страшные вещи не только в PHP, но и в PostgreSql, видали имена столбцов в виде эмодзи?
DeLuxis
28.07.2016 09:19-2Когда стоял выбор изучения следующего языка после РНР и JS, межу Ruby и Python, то из-за синтаксиса, возможностей и гибкости предпочел Python.
iqiaqqivik
29.07.2016 08:16+2Ну синтаксис ладно, а расскажите, как вы определяете «возможности и гибкость» незнакомого вам языка?
DeLuxis
29.07.2016 08:42Библиотеки и опыт использования для различных целей у других людей. Читаю форумы и другие площадки. Как бы мнение не сложно сложить.
iqiaqqivik
29.07.2016 09:32+4Мнение-то сложить никогда не сложно. Вот только _правильное_ мнение так сложить практически невозможно.
erlyvideo
28.07.2016 09:41-7боже мой, я эту херню вижу с 2005 года, когда начал писать на рельсах.
Это всё нытьё из серии «PHP не такая уж и дрянь как мы все считаем» и «смотрите, смотрите: в 2016 мы в PHP научились как в рельсах в 2006»
develop7
28.07.2016 13:11Всем известно, что развиваются только и исключительно технологии, за которыми целенаправленно следишь.
Cryvage
28.07.2016 13:20+6смотрите, смотрите: в 2016 мы в PHP научились как в рельсах в 2006
Лично я, смысл статьи понял как «в 2016 в PHP можно делать так же, как в рельсах в 2016. Но при этом в PHP есть много фреймворков, и если rails-like фреймворк не подходит, то всегда есть выбор.» Рельсы вообще очень удачное название. Руби как на них встал, так теперь и не может свернуть, ведь именно рельсы задают направление. Было бы гораздо лучше, будь у рельсов хотя бы один конкурент.
Отчасти я согласен, что все это больше похоже на нытье, но в то же время, имеют же люди право свое мнение высказывать.filipov_a
28.07.2016 16:19+1Было бы гораздо лучше, будь у рельсов хотя бы один конкурент.
Sinatra, Padrino, Hanami, Grape.
Мы, например, отказались от Rails.
AlexLeonov
28.07.2016 09:47+5Ну что же. Большой респект и автору, и переводчику, рискнувшему выставить этот перевод на публику. Респект за смелость.
То, о чем говорит автор, давно уже назрело. Просто не принято было говорить вслух. Все последние годы считалось среди программистов средней руки хорошим тоном на публику кричать «пых — говно, руби рулит!», а тем временем потихоньку пилить проекты на Wordpress и, прости господи, Битриксе ради булочки с маслом.
Руби — мёртв. И уже поздно обсуждать, как его реанимировать, нужно понять — как же это получилось? Как так вышло, что PHP, язык «быдлокодеров» внезапно (sic!) оказался более гибким, более быстрым, более правильным в архитектурном смысле, расцвел в пышную экосистему множества отличных фреймворков, а «илитный» Ruby лежит и плохо пахнет?
Имхо, анализ сводится к трем пунктам:
1. Монополия. Рельсы убили Руби. RIP они оба. И не только в рельсах дело. Дело в монополии на всё — один (фактически!) фреймворк, один человек, отвечающий за сам язык, одна система пакетов. Нет конкуренции — нет развития.
2. Отсутствие развития самого языка. И даже отсутствие внятных механизмов обсуждения такого развития! Сравните, например, переходы PHP 5 -> 5.3, 5.3->5.4, 5->7. Каждая новая версия — фактически новый язык. Что нового появилось в Ruby за те же годы? А?
3. Сильная связность с окружением. PHP работает везде, на любой ОС, с любым веб-сервером и без него, не требуя ничего от окружения, кроме возможности запустить бинарник «php.exe» (условно). А еще php-fpm.
PHP не пытается быть сервером приложений, он просто честно делает своё дело — принимает запрос, отдает ответ и умирает. Может быть пора перестать воспринимать это, как недостаток дизайна языка?
Всё вышенаписанное — имхо и не отменяет уважения к тем, кто честно делает своё дело, программируя на Ruby и рельсах.VolCh
28.07.2016 09:58он просто честно делает своё дело — принимает запрос, отдает ответ и умирает
Вообще говоря, подобный подход уже давно редкость, разве что в неинтерактивных CLI-инструментах используется. С момента появления mod_php PHP старается быть именно сервером приложений.AlexLeonov
28.07.2016 10:06Не работаю с Apache.
Назвать php-fpm сервером приложений — имхо, неверное употребление термина. Это сервер рабочих процессов. Процессов, которые запускаются и умирают.
И если честно, мне такой подход нравится больше, чем бесконечный цикл приложения.sumanai
28.07.2016 10:13Процессов, которые запускаются и умирают.
Не замечал перезапуска процессов FPM при каждом запросе.
И если честно, мне такой подход нравится больше, чем бесконечный цикл приложения.
Такой подход безусловно проще, но не лучше. У меня всё в мечтах написать что нибудь полезное на неумирающем PHP, к примеру, с помощью Aerys.G-M-A-X
28.07.2016 20:49>Не замечал перезапуска процессов FPM при каждом запросе
Имеется в виду, что весь контекст, все загруженные скрипты, все переменные после окончания запроса пропадают.
Да Вы и сами констатируете отдельно наличие неумираемого PHP…
VolCh
28.07.2016 11:25+1Нет, запускаются и умирают они редко (по умолчанию, емнип, один раз на 500 запросов), на каждый запрос при использовании php-fpm происходит лишь очистка доступного разработчику окружения, прежде всего глобальных и суперглобальных переменных и непостоянных файлоподобных ресурсов. Это выглядит «изнутри» почти как «запустился и умер», но только почти, только почти.
AlexLeonov
28.07.2016 13:14Речь не про реализацию пула процессов и прочего. А про то, как оно выглядит для разработчика, да.
sumanai
28.07.2016 10:06Между запросами очищается довольно много всего, поэтому и говорят о умирающей модели.
Редко кто делает на PHP приложения, которые один раз инициализируются и далее обрабатывают запросы, в большинстве случаев инициализаия происходит каждый раз.VolCh
28.07.2016 11:28Спасибо за объяснение, но оно излишне, я с PHP3 начинал, в том числе используя его через чистый CGI (переписывал приложение с Perl) и знаю разницу между «умирать» и «делать вид что умираешь».
sl_bug
28.07.2016 10:36+9Есть подозрение что про руби вы знаете только название…
> Монополия. Рельсы убили Руби. RIP они оба.
в чем это выражено?
> одна система пакетов
эрлангу это не мешает, или тоже мёртв?
> Что нового появилось в Ruby за те же годы? А?
читайте changelogs и удивляйтесь
> Сильная связность с окружением.
серьёзно? «ruby.exe» куда-то удалили? ruby не работает с apache/nginx/cowboy?
> PHP не пытается быть сервером приложений
а руби вот прям пытается…
crmMaster
28.07.2016 14:29-2Просто люди очень компетентные в рельсах обсуждают статью очень компетентного автора, который полтора года потрахался с рельсами, в результате не осилил даже философию руби.
iqiaqqivik
28.07.2016 14:43Кстати, в последнее время на SO очень много людей пришли в руби рубрику явно из php, и я буквально каждый второй ответ начинаю с фразы «this is an attempt to write php with ruby syntax».
MetaDone
29.07.2016 22:38> одна система пакетов
эрлангу это не мешает
https://hex.pm/
http://synrc.com/apps/mad/
sharikov_d
28.07.2016 11:55+12Руби — мёртв.
А мужики-то и не знали, пойду расскажу!
Как так вышло, что PHP, язык «быдлокодеров» внезапно (sic!) оказался более гибким, более быстрым, более правильным в архитектурном смысле, расцвел в пышную экосистему множества отличных фреймворков, а «илитный» Ruby лежит и плохо пахнет?
более гибким, более быстрым, более правильным
кроме мантры ничего не вижу, по существу можно?
Никто не заставляет использовать ActiveRecord, никто не запрещает писать отдельно операции/обжекты. Более того, криворукий кодерок может написать говнокод абсолютно на любом языке.
2. Отсутствие развития самого языка. И даже отсутствие внятных механизмов обсуждения такого развития! Сравните, например, переходы PHP 5 -> 5.3, 5.3->5.4, 5->7. Каждая новая версия — фактически новый язык. Что нового появилось в Ruby за те же годы? А?
Вы вообще следите за руби-комьюнити? написали хотя бы тысячу строк? Просто какие-то толсто-зеленые тезисы без аргументов
3. Сильная связность с окружением. PHP работает везде, на любой ОС, с любым веб-сервером и без него, не требуя ничего от окружения, кроме возможности запустить бинарник «php.exe» (условно). А еще php-fpm.
Не знаю, никогда не работал под виндой, но часто ли вы встречали приложения которые в продакшене крутятся на винде?
AlexLeonov
28.07.2016 13:12-4На последний ваш тезис: да, встречал. Не вижу никакой проблемы.
На всё остальное: имхо еще долго люди, вложившие 3-5-7 лет своей жизни в Руби будут сопротивляться очевидным фактам и ставить минусы в карму тем, кто констатирует давно понятный факт: Руби сдох, надо слезать…
Жаль, конечно. Но, имхо (опять же!), раз вы переходите на аргументы типа «Сперва добейся!», предмета для спора нет.sharikov_d
28.07.2016 13:34+3очевидным фактам
Назовите их, я, как разработчик на руби, не вижу их. Почему мне надо слезать с этого прекрасного языка? Прошу, откройте мне истину!
iqiaqqivik
28.07.2016 13:46+6давно понятный факт: Руби сдох, надо слезать
Я, судя по вашему апломбу и глупости, постарше буду, поэтому позволю себе рассказать вам несколько интересных вещей. PHP сдыхал на моей памяти три раза: в 2006, когда рельсы стали похоже на продукт, в 2012 (кажется), когда нода стала похожа на продукт, и в 2014, когда все хором заявили, что теперь заживем в вебе на го. И ничё, живет, пованивает конечно, но умирать не собирается.
Не знаю, кому там и что понятно, но по статистике гитхаба все хорошо, а статистика закрытых говносайтиков безыменных говноконторок — это хорошо только девочек охмурять.
Многие профессиональные рубисты недолюбливают рельсы. Я не пишу на рельсах принципиально, работая в крупном финтехе. Пишу на руби. Много у вас там вокруг программистов, которые пишут на PHP, но принципиально не работают с фреймворками? Сомневаюсь, и могу рассказать, почему: язык слишком бедный.
Ну и, наконец, мы-то переходим с руби: внутрь эрланговой виртуальной машины, используя написанный рубистами синтаксический сахар к эрлангу под названием Elixir. А куда пойдут похаписты, когда оно окончательно сдохнет? Ой, не знаю.
VolCh
28.07.2016 13:54+3А куда пойдут похаписты, когда оно окончательно сдохнет?
Не дождётесь :) А если серьёзно, то, имхо, если сохранится тренд развития последних лет, то логичным будет переход на Java/C#. С другой стороны многие пехепешники неплохо знают JavaScript, причём с последними трендами не только клиентский, но и серверный. Например, для среднего миддла ) не должно составить труда написать на javascript веб-сокет сервер, который будет шарить сессии с http-сервером на PHP и дергать его как API.iqiaqqivik
28.07.2016 14:41:)
Ну не все же настолько всеядны, чтобы на js переходить без анестезии. C# только кажется простым, идеологически он гораздо извращеннее php, так что не уверен. Java — про другое совсем, поломать внутри все паттерны не так-то просто (а многим еще и неохота).
G-M-A-X
28.07.2016 21:00>С другой стороны многие пехепешники неплохо знают JavaScript, причём с последними трендами не только клиентский, но и серверный.
Вряд ли. У серверного JS совсем другая философия, как мне показалось.
Говнокодинг не в счет.
VolCh
29.07.2016 02:02У серверного JS совсем другая философия, как мне показалось.
Угу, «Товарищи! Рабоче-крестьянская революция, о необходимости которой всё время говорили большевики, совершилась!», теперь необходимости на каждый запрос выстраивать окружение с нуля нет :)
G-M-A-X
28.07.2016 20:58+1>Я не пишу на рельсах принципиально, работая в крупном финтехе. Пишу на руби.
Уважаю.
>Много у вас там вокруг программистов, которые пишут на PHP, но принципиально не работают с фреймворками?
Мало. Я один из них :) С фреймворками не работаю не то что принципиально, просто они унылые.
>Сомневаюсь, и могу рассказать, почему: язык слишком бедный.
Не знаю, мне язык не показался бедным. Библиотека PHP, наверное, самая богатая.
Недавний пример. Тут у нас у клиента на Java сломался парсер JSON, там он по ходу пишется вручную каждым программистом. :) В php же для этого всего одна функция: json_decode().iqiaqqivik
28.07.2016 21:13+1Я не про библиотеку, я про средства выразительности самого языка. Самые выразительные, разумеется, LISP и (с небольшим отставанием) Erlang. Ну вот например задача: средствами языка написать логгер, который включается только в dev-режиме, а в продакшене не добаляет ни единой лишней инструкции процессора (high-load, то-сё). На руби у меня это получилось в 20 строчек.
Даже на Java с AspectJ это гораздо более громоздко и менее интуитивно. Боюсь, что на PHP это совсем заковыристая задача.
Ну и руби позволяет писать функциональный код, а функциональный map-reduce банального массива в PHP — это же трэш и угар, натурально.
saggid
28.07.2016 21:36функциональный map-reduce банального массива в PHP — это же трэш и угар, натурально.
https://laravel.com/docs/5.1/collections#method-map
https://laravel.com/docs/5.1/collections#method-reducesaggid
28.07.2016 21:43А также нативные методы array_map и array_reduce.
sl_bug
28.07.2016 22:17и лапша из скобок в виде array_merge(array_map(array_something_else))))
saggid
28.07.2016 22:51Даже если у вас эта ненависть к функциям в скобках — возьмите класс коллекций из ларавел (он легко забирается в любой другой пхп проект, так как не имеет почти никаких зависимостей) и пишите все в стиле вызовов методов к массивам. Я дал ссылки наверху на пример же, каким образом вы смотрите на мои сообщения? Просто чтобы поспорить и «пошпынять php» в очередной раз?
sl_bug
28.07.2016 23:16-1Нет, не пошпынять. Просто частичное ФП в пхп очень плохо реализовано. и это факт.
Да до реальных ФП с пайпами ему далеко, но вещь в видеsome_var.map(&:method).inject(&:method).something(&:method)
можно было бы придуматьsaggid
28.07.2016 23:29+1PHP по другому смотрит на объекты и примитивы, это разница в идеологии и философии программирования. И при желании, вы можете использовать что-нибудь вроде вышеупомянутого мною класса коллекций из Ларавел. Никто вам этого не запрещает. Тогда вполне можно писать код в таком стиле, например:
$jsonUsersFilteredAndGroupedByCity = collect($usersArray) ->filter(function ($user) { return $user->age > 20; }) ->groupBy('city_id') ->toJson();sl_bug
29.07.2016 00:22а теперь добавьте в функцию фильтра внешнюю переменную. ой, уже какой-то use нужно делать непонятно за чем. ах да, это же ООП
saggid
29.07.2016 01:06+1Всё-таки видно, что пришли поспорить, а не к истине придти. Мне вам доказывать теперь, что ООП — это хорошо?) Пожалуйста, пользуйтесь чем хотите, но в мире программирования, отличии от мира реального, нет Единственной Истинной Религии, если вы своими комментариями пытаетесь претендовать на это.
sl_bug
29.07.2016 01:16погодите, все началось с map-reduce в пхп без фреймворков. без споров. покажите как это сделать красиво и читабельно в пхп
saggid
29.07.2016 01:18Я же кидал ссылки на красивые решения в своём комментарии выше :)
sl_bug
29.07.2016 01:21ну я и привел пример — как там внутри красиво использовать внешнюю переменную? (и да я в курсе что это не совсем functional way). и советую потом видео все-таки досмотреть
sl_bug
29.07.2016 01:25особенно внимание обратить на инкапсуляцию
saggid
29.07.2016 01:51Прокрутил видео, да, я знаю об основах функционального программирования, об иммутабельности, и прочем. Это всё хорошо, но я не вижу причину называть ООП злом только из-за одного видеоролика на ютубе. Иначе все бы мы уже давно использовали только функциональные подходы.
Картинка мало относится к PHP, если честно. Там не так уж часто объекты зависят от состояния друг друга, так как его логика работы слишком простая: получил запрос — вернул ответ, умер. Объекты если и шарятся между компонентами, их состояние не изменяется каким-то кардинальным образом.
как там внутри красиво использовать внешнюю переменную?
Именно так, как вы и сказали — через добавление
useконструкции к объявлению анонимной функции. Опять же, не вижу особых причин для обсуждения этой части PHP: это не сильно мешает при разработке.sl_bug
29.07.2016 08:29Вы не поняли посыл видео. ООП не работает нигде в том варианте как было задумано. То что вы называете ООП есть не ООП
VolCh
29.07.2016 02:04+3Это просто такой синтаксис замыканий. Явное лучше неявного типа.
iqiaqqivik
29.07.2016 08:30-3Ну да, такой синтаксис, конечно.
Да, можно привыкнуть. Но «явное лучше неявного», вы уж меня великодушно простите, это просто вообще не про php. Не нужно пытаться из табуретки сделать велосипед. Можно привыкнуть к тому, что ноль целых ноль десятых равен символу нуля, но они по разному себя ведут под ифом, можно. Но вот не надо после этого костыль (use) называть «таким синтаксисом», ладно?
saggid
29.07.2016 09:30Сорян, я запарился спорить с вами. Займитесь делами, пишите на чем хотите, я не ваш пастух в любом случае.
iqiaqqivik
29.07.2016 09:37-6Вы не пастух, разумеется; вы просто недалекий, невнимательный и невежливый джуниор.
А спорить вы запарились (правда, не со мной, но протереть глаза я вам бессилен), потому что у вас нет ни единого аргумента. Такие дела.
iqiaqqivik
29.07.2016 08:26-6Вы сами себе и ответили.
Если в ответ на реплику о (заострите все ваше внимание, на секундочку, пожалуйста) средствах выразительности самого языка, вы сами же приводите ссылки на стороннюю библиотеку, значит с синтаксисом языка все очень плохо. И это не экзотика какая-нибудь, это map-reduce.
Source
30.07.2016 01:25А, кстати, вопрос про стандартную библиотеку: её хоть с выходом PHP 7 причесали в плане консистентности? Или такой же бардак как в 5.1 по-прежнему?
sumanai
30.07.2016 05:02+2Самую малость. Убрали замшелое старьё типа mysql_ функций, а так всё по старому.
В 7.1 немного улучшат в плане строковых функций, но тоже не критично.
В угоду совместимости никто не будет выкидывать беспорядочный ворох функций.
Если кому-то хочется использовать консистентно функции строк и массивов, то советую расширение, позволяющее делать вот так:
$string = "abc"; var_dump($string->length()); // int(3) var_dump($string->startsWith("a")) // bool(true)Source
30.07.2016 12:03Ну что ж, радует, что есть какой-то прогресс и в этой области.
Расширение крутое, но будет лучше, когда подобные возможности появятся в самом языке. Это, кстати, хороший вариант и обратную совместимость сохранить ещё на пару версий и параллельно новую согласованную stdlib сделать.VolCh
30.07.2016 14:26+2Подобное расширение языка потребует введение стандартных типов String, Int и т. п. к которым неявно будут преобразовываться строки, числа и т. п. в объектном контексте и обратно в скаляры в скалярном. Либо делать все переменные объектами изначально, что довольно накладно. Это возможно, наверное, но довольно трудозатратно и сильно изменит язык (сильнее чем тот же скалярный тайпхинтинг). С другой стороны мало есть смысла просто перебрать существующие функции, улучшив их сигнатуры — работы много, польза небольшая.
kir_vesp
28.07.2016 11:56+2- Монополия — ну, фрэймворки есть и иные, просто никто ими не занимается. Проблема кмк в том, что многие прогеры считают руби "несерьёзным и хипстерским", хотя при этом недостаточно хорошо осведомлены о его реальных возможностях(а ведь можно и небольшие десктопные приложения ваять). А рельсы убивают руби тем, что большинство на этом и останавливается, хотя у языка достаточно и иных возможностей. Например, при обработке текстов и парсинге страниц я предпочитаю короткие скрипты на руби с его Nokogiri.
По остальным пунктам сказать нечего, всё так.
З.Ы. Занимаюсь разработкой на yii и сайд-проектами на RoR. Последнее время единственным legacy стал считать проекты на RoR, ибо там такое бывает, что просто умереть не встать)
youlose
28.07.2016 13:16+4Ох уж эти пророки… Вроде бы живём в информационный век, а Ванги не перевелись…
Языки программирования не могут умереть, есть мера интереса общественности к ним. Судя по рейтингу TIOBE интерес к Ruby растёт http://www.tiobe.com/tiobe_index, причём динамика резвее чем у PHP. Так что о чьей либо смерти говорить совсем преждевременно. Да и PHP уже не в тренде, в тренде Java и Javascript, последний из которых упрямо лезет в нишу пхпни и успешно вытесняет её оттуда, а вот нишу Ruby никто из них занять не может (быстрая разработка с понятным и поддерживаемым кодом).
Про «илитность» Ruby, говорят в основном PHPшники с узким кругозором, которые только на хпх и умеют говнякать. Я вот лично имею проекты и на Ruby и на PHP (даже Python и Golang присутствует) и ни о какой элитности ни одного из языков не вижу в принципе, у каждого есть своя ниша, свои задачи и даже свои клиенты с определёнными особенностями психики…
Про пункты глупости написаны:
1. Вот вы гвозди чем забиваете? Всё ещё молотком? Фи… Монополия… Надо выдумать какой-нибудь «шмолоток»?
На руби, если изволите поинтересоваться, кроме рельсов есть и другие фреймворки (Grape, Sinatra, Jekyll, это только те, которыми лично я пользуюсь параллельно с рельсами), известность рельсов обусловлена тем что они очень грамотно и качественно сделаны, бурно развиваются и имеют уникальные фичи и технологии (те же Turbolinks и ActiveRecord (в PHP модно кричать что мы реализовали AR, но там даже десятой доли того что есть в рельсах не реализовано, попробуйте выполнить подзапрос с фильтрацией в любом PHP ORM, например), подобия которых в php фреймворках нет и непонятно будут ли.
2. И что же добавили в PHP в этих версиях? Исправили кривое ООП на Java стиль? У Руби с этим проблем не было давно. По сути суть изменений PHP это вычищение deprecated авгиевых конюшен и борьба за улучшение производительности, потому что выяснилось что «крутые» и разнообразные ООП фреймворки на PHP жутко тормозят =).
В Руби, как ни странно обновления также выходят с завидным постоянством и переходить между версиями НАМНОГО легче чем у PHP, у меня, к примеру есть сервер со старыми CMS и php 5.2 и обновляться он уже никогда не сможет. А настроить разные среды с разными версиями в пределах одного сервера для PHP нетривиальная задача.
3. Тут вообще художественный свист, откуда же тогда берутся подобные говнотворения http://www.denwer.ru/ и люди мучаются разбираясь с ними днями?
Из нескольких десятков пхпшников что я знаю ни один не сможет поднять php-fpm (упомянутый выше) хотя бы за один день.
Про бинарник php.exe, я предлагаю попробовать, а потом уже разглагольствовать.
При всём при том, что на рубях все фреймворки умеют просто и изящно работать локально (для разработки) из коробки. Простые проектики на php действительно разворачивать в продакшн обычно проще, но в средних и больших проектах у PHP сказывается отсутствие инструментов (или их зачаточное состояние) на скорость и удобство деплоя.
Про сервер приложений, автор вообще не особо понимая что пишет написал судя по всему…
atc
28.07.2016 13:27>В PHP модно кричать что мы реализовали AR, но там даже десятой доли того что есть в рельсах не реализовано, попробуйте выполнить подзапрос с фильтрацией в любом PHP ORM, например, подобия которых в php фреймворках нет и непонятно будут ли.
Простите, а в чем проблема? В среднестатистическом AR (для примера возьмем тот, что в Yii2) с подзапросами работать более чем удобно, любой relation легко фильтруется в анонимных функциях, просто приведу пару строк из документации:
$customers = Customer::find()->joinWith([
'orders' => function ($query) {
$query->andWhere(['>', 'subtotal', 100]);
},
])->all();
VolCh
28.07.2016 13:30при всём при том, что на рубях все фреймворки умеют просто и изящно работать локально (для разработки) из коробки.
PHP сам умеет работать для разработки из коробки. php [options] -S : [-t docroot] Всё, даже фреймворки не нужны.
но в средних и больших проектах у PHP сказывается отсутствие инструментов (или их зачаточное состояние) на скорость и удобство деплоя.
capistrano, puppet — зачаточные? )
Про сервер приложений, автор вообще не особо понимая что пишет написал судя по всему…
Как я понимаю, он имел в виду, что в PHP для создания типового сервера не нужно писать ни строчки кода, серверные функции берёт на себя среда исполнения, а приложение (для разработчика) работает по CGI, а на Ruby обычным является написание сервера на Ruby или использование написанного другими типа Thin.
VolCh
28.07.2016 13:47в PHP модно кричать что мы реализовали AR
В PHP модно кричать «AR — отстой, DM — наше всё», имея в виду Doctrine 2.
atc
28.07.2016 13:48+1Ну и про «несколько десятков php-шников, неспособных установить php-fpm за день» — у вас явный логический провал, особенно если учесть, что сам процесс установки — всего лишь несколько консольных команд. Из чего можно вывести следующие варианты:
1) им не нужен php-fpm и они его никогда его не устанавливали
2) не знают linux и не имеют опыта работы в окружении, отличном от shared хостинга
3) новички, не умеющие в чтение документации и английский язык
Все три пункта совершенно невозможны для php программиста, пишущего под тот или иной фреймворк, следовательно ваше утверждение в принципе некорректно.G-M-A-X
28.07.2016 21:18Разве программист должен заниматься установкой серверного софта?
Может, но не должен. :)
script88
28.07.2016 13:51Я даже больше вам скажу, большая часть PHP разработчиков не в состоянии определить, в каком режиме работает PHP.
По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.atc
28.07.2016 13:54-2PHP разработчики не в состоянии посмотреть в конфиг вебсервера или в хедеры в ответе сервера? Я не знаю таких людей, которые при этом писали бы с использованием любого php фреймворка.
script88
28.07.2016 13:56+2Увы, а я знаю.
atc
28.07.2016 14:01-1Расскажите, как это возможно? В данный момент все современные php фреймворки используют composer (пакетный менеджер), что предполагает активное использование консоли, как на этапе разработки, так и на этапе деплоя. Самостоятельно деплоить проект и не знать, как настроено окружение? Что-то тут не сходится, уж простите.
mayorovp
28.07.2016 14:13+1На этапе разработки консоль не нужна (особенно если не отлаживать), а деплой и автоматизировать можно.
atc
28.07.2016 14:17-1Как устанавливать\удалять composer пакеты без использования консоли? Почему автоматизицией деплоя и настройкой инфраструктуры\проекта под неё занимаются разные люди?
mayorovp
28.07.2016 15:02Зачем устанавливать и удалять composer пакеты при разработке? Неужели отсутствие пакета помешает открыть Блокнот и поправить пару файлов?
atc
28.07.2016 15:10Библиотеки тоже в блокноте писать? Давайте не углубляться в демагогию.
Смысл в том, что у аудитория этой статьи (людей, перед которыми может встать выбор Rails\условный Symfony) в любом случае имеются навыки как работы с консолью, так и настройки окружения, это просто повседневная задача.
Потому меня слегка удивляют утверждения, что человек продолжительное время использующий cli для разработки и деплоя что-то там не может настроить на сервере.mayorovp
28.07.2016 15:49В этой ветке обсуждалась не "аудитория статьи", а "средний видимый PHP-программист".
И речь шла именно о том, что полно PHP-кодеров, которые не используют cli для разработки и деплоя.
foxmuldercp
28.07.2016 23:39Средние погромизды — это вообще печаль — говорю как имеющий опыт в несколько лет работы в хостингах, от саппорта до хостмастера. Наваять 100кб+ .hhtaccess, даже без удаления комментариев со стековерфлоу, где-то у себя под denwer'ом, и потом доставать техподдержку «почините ваш хостинг, он говно, в нём мой суперсайт не работает».
iqiaqqivik
28.07.2016 15:17Спасибо, это прекрасно.
Не хотел портить вам статистику по тем, кто воспринимает все за чистую монету, но не смог сдержаться, простите :)
script88
28.07.2016 14:26Погодите, с чего вы взяли, что речь идет исключительно о frameworks и compser? В PHP мало проектов которые не используют composer?! Поверьте, таких проектов очень много, как больших так и маленьких.
Деплой у нас был через CI(Bamboo). Разработчику нужно было закоммитить изменения git repo и написать миграции для БД.atc
28.07.2016 14:35Статья о сравнении Rails с фреймворками из мира PHP, цмс и подобные системы учитывать смысла не имеет — потому что ruby как платформа практически не предоставляет альтернатив. Следовательно композер в предполагаемом php проекте — обязательный элемент.
Относительно деплоя — трогать .htaccess или настраивать проект под окружения должен именно тот — кто конфигурировал CI, остальных разработчиков эта задача не должна затрагивать от слова совсем. Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm».
Другими словами — вы описываете случай, совершенно невозможный при адекватном разделении обязанностей, к качеству php разработчиков это имеет довольно мало отношения.mayorovp
28.07.2016 15:11В файле .htaccess, по сути, в виде modrewrite-правил записываются основные входные точки для приложения — а потому заниматься им должен именно что разработчик.
Просто потому что проще самому написать эти самые правила, чем объяснять админу их на словах.
Ничего общего с настройкой проекта под окружение это не имеет — потому что эти правила будут одинаковы во всех окружениях.
atc
28.07.2016 15:16А если на сервере php-fpm? Выше рассматривается именно этот момент.
Если человек пишет какой-то зависящий от окружения код или конфиги — он должен быть в курсе этого окружения. Если рассматривать ваш пример (с админом) — то последний должен был выкатить подробное readme, что делает невозможным вышеописанный случай.
VolCh
28.07.2016 15:33В файле .htaccess, по сути, в виде modrewrite-правил записываются основные входные точки для приложения — а потому заниматься им должен именно что разработчик.
Этот разработчик должен быть в курсе в каком окружении работает его проект. Он должен быть в курсе, что проект крутится под апачем, что использование .htaccess настроено в принципе и конкретно в тех местах, где он его пишет. Либо админы должны быть в кусре ожиданий разработчика о среде исполнения и настроить её для него.
Либо ему админы должны ткнуть пальцем куда и в каком формате ему настраивать точки входа, либо он должен ткнуть пальцем для админов, где лежать конфиги, сообщить чего этого конфиги и поставить задачу сделать так, чтобы они работали.mayorovp
28.07.2016 15:54Бывает, что на проект взяли нового разработчика, который вообще не в курсе, что существуют какие-то окружения кроме "дефолтного" apache + mod_php — а потому не видит необходимости спрашивать.
Если разработчик адекватен, а коллеги не ленятся объяснять — то эту ошибку он сможет допустить ровно 1 раз в жизни. Но от одного раза не застрахован никто :)
VolCh
28.07.2016 16:07По хорошему это даже не он должен спрашивать, а ему сообщить на этапе вхождения в проект без всяких напоминаний. Я обычно именно так начинаю: «наш проект крутится на хапрокси+нжинкс+пхп-фпм+постгрес+редис+раббит+нода+плюс несколько бинарников на си — со всем встречался?»
script88
28.07.2016 15:26+1Окей, давайте пойдем по другому, есть такой продукт как CMS\CMF Bitrix. Composer в Bitrix проектах используется редко, особенно в тех проектах, где разработка началась 2-3 года назад.
Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как
Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm»
Как показывает практика, документация практически всегда устаревшая, это не только в маленьких но и больших компаниях.
Другими словами — вы описываете случай, совершенно невозможный при адекватном разделении обязанностей, к качеству php разработчиков это имеет довольно мало отношения.
Я описываю случай, который я лично наблюдал и тут дело не в разделении обязанностей, а в компетенции специалиста.
Вот еще один момент вспомнил, когда разработчик хранил cache, php сессии в memcached(Не спрашивайте, зачем он это делал, но это было так), очищал его (memcflush --servers=localhost:11211) искренне удивлялся тому, что у него слетала авторизация в локальном проекте.VolCh
28.07.2016 15:35Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
Кто ему поднимал это дев-окружение? Почему оно оказалось отличным от продакшена? Если сам, то на основании чего? Устаревшей документации?
atc
28.07.2016 15:41Bitrix это хорошо, но он находится вне контекста данной статьи, потому что он:
а) не является фреймворком общего назначения
б) не является альтернативной rails
Да, вполне возможно описанные вами проблемы могли возникать, но это другой мир с другими программистами и совершенно иными типами проблем. Для аудитории статьи сложности в вопросах настройки «php-fpm» просто нехарактерны, о чем я и писал выше.
> Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
Которое должно автоматически развертываться и быть одинаковым для всех разработчиков.script88
28.07.2016 15:51Должно, но мы живем не в идеальном мире. Везде есть своя специфика и нюансы и эти проблемы свойственны в любой среде.
atc
28.07.2016 15:54+1Совсем нет, придуманы сотни инструментов, ansible, puppet, vagrant, docker, системы непрерывной интеграции и деплоя, если при таком гигантском инструментарии все еще продолжают возникать проблемы — то пенять нужно явно не на квалификацию программистов, а на того, кто организует рабочий процесс.
script88
28.07.2016 16:07Вы уходите совершенно в другое русло. Ситуации бывают разные, нет идеальных работников. Если разработчик компетентен во многих вопросах, то он смело может ткнуть носом adm\devops в то место и аргументирует свое решение.
atc
28.07.2016 16:18Вернемся выше:
> Я даже больше вам скажу, большая часть PHP разработчиков не в состоянии определить, в каком режиме работает PHP. По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.
Почему не в состоянии?
1) сервер настраивал нехороший человек, который не утруждался документированием
2) деплой настраивал не менее плохой человек
3) при этом на разработчика повесили задачу, зависящую от окружений, ни о чем не уведомив
Это не является ни проблемой программиста, ни его косяком, и тем более — такое не стоит приводить в пример, как типичную ситуацию.
VolCh
28.07.2016 16:13Да даже не в инструментарии дело, в конце-концов для новых участников проекта должна быть инструкция по разворачиванию хотя бы дев-среды. Из пары команд типа git clone… && vagrant up или длинный талмуд со скриптами на 5 языках, но должна быть. А если нет, то пенять нужно, да, на того, кто организует процесс, на того, кто не поставил задачу задокументировать процесс разворачивания.
G-M-A-X
28.07.2016 21:08>«крутые» и разнообразные ООП фреймворки на PHP жутко тормозят
Согласен. Я это постоянно говорю. Но илита загоняет меня в минуса и ридонли :)
>А настроить разные среды с разными версиями в пределах одного сервера для PHP нетривиальная задача.
Я руками с исходников себе ставил.
Или пользуйтесь шаред хостингом.
И обновлялся практически бескровно 5.2-5.3-5.4-7.0
>Из нескольких десятков пхпшников что я знаю ни один не сможет поднять php-fpm (упомянутый выше) хотя бы за один день.
На винде оно какое-то кривое стало с 2009 года, поэтому пользуюсь OpenServer. Я в 2008 как новичек все сам поднимал без проблем.
П.С.
Пробовал также и руби, ставил редмайн. :)MetaDone
29.07.2016 23:24>«крутые» и разнообразные ООП фреймворки на PHP жутко тормозят
Согласен. Я это постоянно говорю. Но илита загоняет меня в минуса и ридонли :)
http://govnokod.ru/19878
Ваше мнение и гроша ломанного не стоит, т.к. вы некомпетентны совсем, или же уже 3 аккаунт тупого тролля (не жирного, именно тупого, который показывает недостаток наличия аккаунтов без инвайта с возможностью что-то комментировать)G-M-A-X
30.07.2016 00:55-2О-хо-хо.
Вы сидите в тьюринговой трясине: https://habrahabr.ru/post/139535/
:)
sumanai
29.07.2016 01:35+1А настроить разные среды с разными версиями в пределах одного сервера для PHP нетривиальная задача.
Я пользуюсь вот этим репозиторием, установка версий 5.6 и 7.0 была элементарной.saggid
29.07.2016 02:25Да, подтверждаю. В системе после установки появляются разные бинарные файлы:
php5.6иphp7.0, что полностью решает все проблемы с запуском различных версий PHP на одной машине.
thousandsofthem
28.07.2016 15:12+1Ruby/Rails таки еще не мертв но перспектив развития особо нет и через какое-то время умрет
Про то, что rails плох — пусть хотя-бы один пхп фреймворк будет настолько плох и он станет лучшим пхп фреймвоком из существующих. Серьезно, планка поднята очень высоко и не смотря на серьезные архитектурные проблемы rails все еще живее всех живых
Да даже упомянутый asset pipeline — какие фреймворки из коробки имеют настроенный сборщик ассетов? Ведь оно все равно надо а настраивать это не так тривиально (нужные разные правила для разных окружений, надо уметь hot reload в дев, source maps etc) — зачем тратить тысячи человекочасов на повтор такого раз за разом. Рельсы берут такими вот мелочами — когда за тебя решены вопросы которые все равно придется решать
Про то, что переходить некуда — уже есть. Зовется Phoenix (язык — elixir). Делают люди из команды rails. И таки разработчики на него уже переходят т к все основные проблемы рельс успешно решены. Всячески рекомендую.
iqiaqqivik
28.07.2016 15:20Хосе — не «люди», и он никогда не работал в «команде rails».
thousandsofthem
28.07.2016 15:57Jose Valim — http://contributors.rubyonrails.org/ — #5 по количеству коммитов.
Пусть будет не "в команде" а core contributor тогдаiqiaqqivik
28.07.2016 21:18Contributor — это безусловно. Просто там же очень много политики, как раз вокруг Elixir’а, и мне показалось, что на этом имеет смысл заострить внимание.
В смысле, я про идеолога DHH и его свиту :)
sl_bug
28.07.2016 22:24т.е. команда = dhh?
на самом деле dhh всего лишь один из контрибуторов, но с правом вета. и такие нужны в любом проектеiqiaqqivik
29.07.2016 07:03Нет. DHH — это и есть команда рельс. И именно поэтому, в частности, мы имеем то, что имеем: Elixir, придуманный не от хорошей жизни (насколько мне известно, перед Хосе не стояло никакой практичесой задачи), Solnica, воюющий с ветряными мельницами, плодящиеся адовые коллбэки в AR, откровенные костыли в корке, GFY в твиттере и т. д.
Почитайте любой тред с участием DHH.
develop7
28.07.2016 15:58вы сами найдёте #5 на https://github.com/rails/rails/graphs/contributors или скриншот залить?
hippoage
28.07.2016 10:06+11Очень много всего в кучу собрано, немного прокомментирую.
Rails в 2016 году уже далеко не инновационный фреймворк:
1) всё самое интересное реализовали и другие (и это хорошо)
2) многим проектам на rails уже по многу лет (тому же basecamp),
тут не до экспериментов уже, скорость адаптации новых идей значительно снижается
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Если хочется инновационности, то это все же в строну ECMAScript (Meteor.com например) и Golang, PHP тут не при чем.
Что все еще хорошо в rails?
1) ActiveRecord — как раз в противоположность твиту выше. Хорошо, когда можно начинать с простого (всё в одном классе), а при необходимости уже рефакторить и выделять новые классы.
2) Синтаксис руби — всё-таки он один из самых чистых/читабельных. Можно долго рассуждать про IDE, но это помогает скорее в наборе кода, а не читабельности.
3) Определенный уровень матёрости. Сейчас уже выработаны best practicies и куча библиотек, много материалов для обучения. Все руби библиотеки хорошо работают с rails, проблем в подключении нет. Проблем с поиском библиотеки под задачу не встречал.
Есть давно известные проблемы:
1) производительность ruby — они всегда были, с нулевых версий rails, но никогда особо не считалось важным
2) сложность установки — сейчас при наличии ансиблов с шефами и докерами острота снизалась
3) острота ножей — требуются лучше, чем хорошие программисты
4) добавьте свое
Приоритет рейлс — дать лучшим программистам лучший (приятный и острый) инструмент для производительной (с точки зрения фич) серверной разработки. Рейлс не подходит для «промышленной» разработки (когда команда состоит из одного регуляра и кучки юниоров). Исходя из отдельных фраз, с чем-то подобным столкнулся и автор статьи (например, не должно быть большого количества манки патчей, что-то они явно не так делали).
Раньше было практически невозможно найти программиста на php (в смысле, именно программиста), а в rails стекались лучшие из php и java. Сейчас уже не так: и в php научились программировать, и в рейлсах слишком много курсов «программист за неделю».Comedian
28.07.2016 13:183) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
Какой-то странный аргумент, а у меня сразу все взлетело :)
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
А почему ущербное? И вообще, только API на рельсах можно было писать и до выхода rails 5
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Из всех этих утверждений согласен только с 3.3, хотя тут тоже зависит от реализации
slonopotamus
28.07.2016 10:20+3Summary: еще один программист посмотрел на мир за пределами своего одного язычка и понял что Ruby ничем существенно не лучше PHP. Но в общем-то и не хуже, поэтому он не готов агитировать за переход на PHP. Если бы он посмотрел немного дальше, то обнаружил бы, что к той же группе относятся Python, Perl и всякие модные node.js.
Stan_1
28.07.2016 10:25+4Я в свое время перешел на Rails с PHP по следующим причинам:
1. Удобство поддержки. Жестко определенная структура папок проекта, нейминга дало мне возможность не только быстро анализировать чужие коды, но и вспоминать через полгода «что ж я тут понаписал». В случае с PHP — развитие моих девелоперских навыков мешало мне понять старый код и требовало времени и усилий разобраться в нем.
2. Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
3. Удобное из коробки разделение на среды: development, test, production
4. Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Меня периодически друзья просят посмотреть MODx, сайты на Symphony, но для меня это каждый раз сильный стресс. Нет ощущения — что сейчас полезу в проект, и буду знать, где какие части найти. Ну и плюс каждый раз после такого опыта радуюсь, что имею возможность писать именно на Rails или на чистом Ruby (есть собственный framework для CLI-приложений, не использующий Rails).
Assada
28.07.2016 11:10Жестко определенная структура папок проекта,
Ну не знаю… Кто то диктует вам структуру папок в вашем проекте?
Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
Дело привычки же. Да и скобки лишние. А IDE сделает все за вас.
Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Мне кажется в любом языке четкое разделение. Тем более это разделение можно организовать как угодно и тем более это не проблема языка.Fedcomp
28.07.2016 11:25> Мне кажется в любом языке четкое разделение. Тем более это разделение можно организовать как угодно и тем более это не проблема языка.
Вы это про inline код в php? многие даже почему то считают это best practices. Мол нам шаблонизатор не нужен, у нас php шаблоны! быстро же!atc
28.07.2016 11:47А какая разница, на какой технологии выполнен view слой, если речь именно о разделении? Или вы про потенциальную возможность его нарушить, путем написания inline php в шаблонах? В таком случае — это возможно и на шаблонизаторе, достаточно написать хелпер-другой.
noder
28.07.2016 12:29+1А в Rails в ERB шаблонах разве не inline ruby код?
kir_vesp
28.07.2016 13:03В ERB — да, но тут скорее речь о том, что логика должна разделяться и для ERB существуют именно хэлперы. Т.е. там изначально предоставлен механизм шаблонизации. Пихать туда логику и кучу кода дело сугубо личное(ну нравится некоторым обмазываться), но порицаемое.
VolCh
28.07.2016 12:17Мне кажется в любом языке четкое разделение.
Скорее ровно наоборот, ни в одном (мэйнстрим) языке нет такого разделения. Разделения вносят (если вносят) фреймворки, а чаще вообще соглашения разработчиков типа: «пишем по MVC, контроллеры туда, вьюшки сюда, модельки там лежат».
Stan_1
28.07.2016 16:34В моем проекте никто не диктует. Но мне хотелось бы, чтобы скачав себе чужой проект, найти все файлы ровно там, где я ожидал бы их увидеть. И пока Rails, для меня лично, воплощает это желание лучшим образом.
MetaDone
29.07.2016 23:35мне хотелось бы, чтобы скачав себе чужой проект, найти все файлы ровно там, где я ожидал бы их увидеть
в php-проектах так будет с simfony — все будет на своих местах + интерфейсы на каждый чих, что позволит быстро и безболезненно реализовывать кастомный функционалVolCh
30.07.2016 14:28Справедливости ради, в Symfony настраивается практически всё, включая файловую структуру проекта :)
maxru
28.07.2016 11:51У меня ощущение жёсткого дежавю. То ли перевод этой статьи уже публиковался на хабре, то ли я оригинал читал.
upd. действительно, читал оригинал
iqiaqqivik
28.07.2016 11:55+5Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL.
Конечно, весь мир в последние 10 лет как раз работает над упрочением ООП конструкций.
Я сначала хотел надергать очень смешных цитат, но потом решил, что тогда придется каждое предложение из заметки комментировать.
Поэтому скажу главное: если вглядеться в то, что сейчас делает Piotr Solnica, многократно цитируемый в статье, то это (сюрприз) не переход на PHP. И не переход на Node/Go/Rust/Buzz. И даже не на Elixir, который, надеюсь, постепенно вытеснит рельсы — не потому, что такой прямо ух, а потому, что запускается внутри бима. Так вот, Петр — отчаянный руби-евангелист, и приводить его тезисы против рельс (а часто — и те, кто в теме, прекрасно это знает, — лично против DHH) в качестве аргумента в пользу «руби уже не торт» — может либо очень глупый и несведущий профан, либо злонамеренный подтасовщик. Автор заметки, судя по всему, из первых.
Руби код в 20 раз лаконичнее и выразительнее подавляющего большинства современных языков. Конкуренты у него в этой области — разве что эрланг и отчасти лисп. И поэтому большинство успешных проектов, которым нужно было быстро взлететь без заметных инвестиций его выбирали. Он не лучше, не хуже, он короче.
Для высоконагруженных систем не годятся ни руби, ни пхп. Но до высокой нагрузки в 99% процентах случаев есть время и ремурс все переписать правильно.
Поэтому мне странно в сто пятьдесят первый раз читать сравнительные статьи. Это как если бы Вася опубликовал длинную статью о своей возлюбленной, а тут пришел бы Петя и стал с ним спорить: нет, моя лучше. Одинаково хороший и одинаково безобразный код можно напистаь на абсолютно любом языке программирования.
G-M-A-X
28.07.2016 21:36> Для высоконагруженных систем не годятся ни руби, ни пхп.
А что годится? Сайты на с++? :)
iqiaqqivik
29.07.2016 07:05Зависит от типа хайлоада. Java годится, если уметь ее готовить. Эрланг, если нет серьезной математики. Микросервисы с очень хорошо продуманной архитектурой.
G-M-A-X
28.07.2016 11:56+2> Разработчики начинают использовать Rails. Обучаются только рельсам. Не могут сделать шага без них. Не могут отличить, что является чистым Ruby, а что является рельсовым монки-патчем. Они не видят чего-то лучше этого, да и не хотят ничего лучше.
То же самое и с разработчиками на PHP-фреймворках…VolCh
28.07.2016 12:24+1В экосистеме PHP нет ярко выраженного лидера среди фреймворков и, грубо говоря, на каждом новом проекте есть большая вероятность встретить новый для себя фреймворк. И после изучения двух хочешь-нехочешь, но будешь понимать где фреймворк, а где язык.
kir_vesp
28.07.2016 13:07Но это ведь проблемы не языка, а сообщества. Рельсы инструмент, написанный на Руби. Если сделали кривой молоток, то проблема не в стали, а в инструменте и его производителе.
AlexLeonov
28.07.2016 13:08Видимо сообщество всем довольно и ему больше ничего не нужно?
Чем еще объяснить фактическую монополию Рельс?kir_vesp
28.07.2016 13:32Может тем, что просто на нём есть уже написанные проекты и люди, входя в язык, не знают ничего, кроме рельс. Ну и да это фрэймворк с самыми большим набором "из коробки". Кому надо, те пилят свои форки или сразу пишут на других фрэймворках.
VolCh
28.07.2016 13:55Скорее люди входят в рельсы, а в язык поскольку постольку, иногда даже не понимая, где они используют фреймворк, а где язык.
Ogra
28.07.2016 12:30+2Раньше все ругали ПХП и думали, что же придет ему на смену — Питон или Руби?
И никто не угадал — на смену PHP идет JS (скажите спасибо node.js). Я вот даже не знаю, что по этому поводу можно сказать, потому что JS, на мой взгляд, гораздо хуже PHP, как язык.AlexLeonov
28.07.2016 12:42+1Да ничего ему на смену не идёт. На ближайшие лет пять (а это как раз и есть средний срок жизни платформы в IT) PHP прочно занял первое место в вебе (и рвётся в не-веб). Это стало очевидно после выхода PHP 7.
А лет через пять посмотрим.
Gugic
28.07.2016 14:03-1Со всевозможными штуками, которые дает связка из TypeScript и ES6, javascript становится очень и очень приятным в работе. (Правда мне js и без них нравился)
yul
28.07.2016 15:55Я бы так прямо не сказал, что хуже PHP4-5 (7-й уже не имел возможности заценить), к тому же есть целая тьма языков, компилируемых в js, на любой вкус. Но я больше склоняюсь к elixir как к следующему языку.
saggid
28.07.2016 23:55-1Node.js требует более высокого порога входа всё-таки. Асинхрон, сложности с пониманием и продумыванием архитектуры проекта, с которой до сих пор не сложилось каких-то "лучших практик". Нода штука прикольная, но туда просто так залезть, как на территорию PHP — просто не выйдет.
avost
28.07.2016 13:47+6>class Foo
> MINUTES = 5
>def bar
> MINUTES.minutes.ago
> end
>end
> Обратите внимание на избыточность, которая содержится в указанном мною моменте в то время когда я назначаю значение переменной.
Вы серьёзно? Сначала неправильно назвали константу, а потом, внезапно, удивились избыточности. Вам эти MINUTES для чего? Что они означают, для чего вы их используете? Вот так и незывайте. И тогда, сурпрайз(!), ваша программа заговорит (а может запоёт). От VERY_IMPORTANT_DELAY.minutes.after до, в конце-концов, FEW.minutes.ago
>Так каков же правильный путь для того чтобы сделать 5.minutes.ago в Ruby? Использовать библиотеку Time и сделать это через TimeMath.minutes.decrease(Time.now, 5).
Лопни мои глаза! А чего ж ваши MINUTES не подставили? Получилось бы вообще зубодробительно — TimeMath.minutes.decrease(Time.now, MINUTES).
q1t
29.07.2016 04:46Где то в 2006 первый раз попробовал RoR после покупки книжки по Ruby, с одной стороны все было очень чудесно и волшебно( да же слишком :) ), к сожалению не смог тогда разобраться в самом коде рельс, но свою задачу как фреймворк этот проект выполнял и выполняет на отлично. После было затишье с вебпроектами и затем нужно было переписать PHP проект — я выбрал Го на тот момент, и как мне кажется многое зависит от кода, а не от фреймфорка и/или языка, проект успешно переписал на Го так как был написан отлично, даже с учетом того что я никогда не писал/читал PHP. Хотя вот с Го и вебом не сложилось, видимо привык к full-featured batteries-included™ веб фреймворкам. Опять же сейчас, ради фана так сказать, делаю пару проектов на нынешние популярном Elixir/Phoenix, хотя он тоже уже потихоньку обрастает макросами — хотя код еще пока понятен, по крайней мере для меня. Так же довольно заинтриговал BEAM. В общем к чему все это, PHP Ruby Elixir отличные языки, многое просто зависит от того кто пишет код + для меня лично еще важно сообщество и то что я могу зайти в IRC, Slack, Mailing List и задать свои глупые вопросы и скорее всего найдутся те, кому это не безразлично и помогут. После этого и самому хочется помогать и не холиварить :)
iqiaqqivik
29.07.2016 07:09хотя он тоже уже потихоньку обрастает макросами
Макросы Elixir — это чистый AST, и это его основная killer feature. Макросы не могут сделать код эликсира менее читаемым по определению. И, для вашего сведения, 95% основных операторов в эликсире (включаяcase, иunless— макросы.)q1t
29.07.2016 07:34И, для вашего сведения, 95% основных операторов в эликсире (включая case, и unless — макросы.)
Да, это вроде бы не секрет, на сайте у них в Getting started про это упоминают, и так же
Macros should only be used as a last resort. Remember that explicit is better than implicit. Clear code is better than concise code.
Да и сам фреймворк Phoenix старается быть более явным в этом плане (web/web.ex), есть некоторые моменты которые сложны лично для моего понимания и написаны они с помощью quote unquote. Скорее всего просто у меня мало опыта с этим.iqiaqqivik
29.07.2016 08:20А я не говорю, что это секрет, я просто удивился фразе «потихоньку обрастает макросами».
Macros should only be used as a last resort.
А вот это — чистая защита от нубов. Точно так же, как про руби все пишут: «не используйте манкипатчинг!», а на деле — основной смысл руби в манкипатчинге, просто его нельзя давать в руки обезьянам :)
В эликсире всегда свежая актуальная версия utf-8 именно потому, что Валим принял гениальное решение: он макросами парсит актуальные файлы консорциума с описанием глифов.
Для понимания макросов лучше всего не полениться и прочитать Metaprogramming Elixir Криса Мак Корда (создателя Финикса). Все вопросы отпадут.
sl_bug
29.07.2016 17:52Человек который 1.5 года посвятил руби ради рельсов это ни разу не специалист. Я примерно то же самое могу сказать про C# например. Он не очень
kirilloid
02.08.2016 12:49+3Привет из мира JavaScript:
плюрализм это хорошо, говорили они
будешь учить по фреймворку в неделю, говорили они
TheDeadOne
Или они видели WordPress — самый популярный и самый уродливый с точки зрения архитектуры PHP код, который когда-либо был написан.
Счастливчик автор, не видел битрикса.