Комментарии 203
Счастливчик автор, не видел битрикса.
Откуда такой кипиш?! Раз в месяц кто-то новый пишет, как ему не нравятся рельсы. Ну не нравятся — хорошо. "Но, пожалуйста, не доставайте и не размахивайте им на людях."
Ответная реакция на эти регулярные выпады в сторону PHP, мсье) Пыха нынче уже не тот, может кое-чем и ответить.
0. Включить maintenance mode
1. Залить файлы
2. Настроить конфиги
3. Установить зависимости (composer install)
4. Прогреть кэш генерируемых php-файлов
5. Прогнать миграции базы данных
6. Установить зависимости для фронта (часто npm install)
7. Сбилдтить всё для фронта (webpack например)
8. Включить production mode
Ну и да, в список еще клиетнские зависимости надо добавить (которые через bower install) и что-то, что из разберет по нужным папкам.
6. Установить зависимости для фронта (часто npm install)
7. Сбилдтить всё для фронта (webpack например)
Через npm как правило ставят зависимости именно для сборки фронтенда. Сторонние библиотеки, которые используются непосредственно в работе клиента (типа jQuery или Angular) подтягиваются через bower как правило.
подтягиваются через bower как правило.
это уже давно не так, по сути с тех пор как появились бандлеры намного удобнее использовать npm или модный jspm. Bower полезен только для очень примитивных схем сборки.
По своему небольшому опыту взаимодействия с рельсами (а конкретно периодическое обновление redmine) могу сказать что почти любой проект на PHP гораздо легче поднять чем на рельсах — последний раз особенно доставил переезд на centos 7 — вроде и окружение очень похожее, но все равно пришлось помучиться несколько часов — bundler отказался грузить зависимости из-за конфликтов/ошибок, а гугл как обычно оказался пуст :( И это реально проблема — любую нестандартную ошибку практически невозможно нагуглить, redmine у меня где-то с 2010 наверное и я бы не сказал что стало сильно лучше (обновляю раз в год/два), разве что bundler появился, до него всё еще печальнее было...
Мы деплоили через него статику и шаблоны для java-приложений, довольно универсальная штука, в общем-то. С сильным перекосом в сторону ruby-мира (поддержка того же rvm и рельсов), но это естественно.
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 выглядит как выгрузка файлов по ftp
ваше утверждение тоже верно, так как если я заброшу поддержку приложения, и вдруг обновятся зависимости, то всё упадёт, но я говорю про приложение, над которым ещё идёт (или в перспективе будет идти) разработка, и которое не упадёт в паблик для всех
я просто не знаю: вдруг 90% разработчиков реально разрабатывают opensource для всех, тогда да, я не прав, но в большинстве случаев при обновлении зависимостей происходит исправление каких-то глюков этих самых зависимостей
Из каких шагов состоит деплой RoR и PHP приложений?
Деплой приложения на PHP, ну например популярного Wordpress, согласно этой статье, из 5 шагов.
cap production deploy
Один шаг. Всё остальное это настройка capistrano и подготовка окружения к первому деплою.
— Как развернуть информационную систему X, состоящую из 43 хостов, в т.ч. серверы приложений, кэша, веб-серверы, БД серверы, серверы мониторинга, обработки AMPQ, и так далее?
— Одной командой, ansible-playbook deploy_x_system.yml
Это всё нытьё из серии «PHP не такая уж и дрянь как мы все считаем» и «смотрите, смотрите: в 2016 мы в PHP научились как в рельсах в 2006»
смотрите, смотрите: в 2016 мы в PHP научились как в рельсах в 2006
Лично я, смысл статьи понял как «в 2016 в PHP можно делать так же, как в рельсах в 2016. Но при этом в PHP есть много фреймворков, и если rails-like фреймворк не подходит, то всегда есть выбор.» Рельсы вообще очень удачное название. Руби как на них встал, так теперь и не может свернуть, ведь именно рельсы задают направление. Было бы гораздо лучше, будь у рельсов хотя бы один конкурент.
Отчасти я согласен, что все это больше похоже на нытье, но в то же время, имеют же люди право свое мнение высказывать.
То, о чем говорит автор, давно уже назрело. Просто не принято было говорить вслух. Все последние годы считалось среди программистов средней руки хорошим тоном на публику кричать «пых — говно, руби рулит!», а тем временем потихоньку пилить проекты на 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 и рельсах.
он просто честно делает своё дело — принимает запрос, отдает ответ и умирает
Вообще говоря, подобный подход уже давно редкость, разве что в неинтерактивных CLI-инструментах используется. С момента появления mod_php PHP старается быть именно сервером приложений.
Назвать php-fpm сервером приложений — имхо, неверное употребление термина. Это сервер рабочих процессов. Процессов, которые запускаются и умирают.
И если честно, мне такой подход нравится больше, чем бесконечный цикл приложения.
> Монополия. Рельсы убили Руби. RIP они оба.
в чем это выражено?
> одна система пакетов
эрлангу это не мешает, или тоже мёртв?
> Что нового появилось в Ruby за те же годы? А?
читайте changelogs и удивляйтесь
> Сильная связность с окружением.
серьёзно? «ruby.exe» куда-то удалили? ruby не работает с apache/nginx/cowboy?
> PHP не пытается быть сервером приложений
а руби вот прям пытается…
Руби — мёртв.
А мужики-то и не знали, пойду расскажу!
Как так вышло, что PHP, язык «быдлокодеров» внезапно (sic!) оказался более гибким, более быстрым, более правильным в архитектурном смысле, расцвел в пышную экосистему множества отличных фреймворков, а «илитный» Ruby лежит и плохо пахнет?
более гибким, более быстрым, более правильным
кроме мантры ничего не вижу, по существу можно?
Никто не заставляет использовать ActiveRecord, никто не запрещает писать отдельно операции/обжекты. Более того, криворукий кодерок может написать говнокод абсолютно на любом языке.
2. Отсутствие развития самого языка. И даже отсутствие внятных механизмов обсуждения такого развития! Сравните, например, переходы PHP 5 -> 5.3, 5.3->5.4, 5->7. Каждая новая версия — фактически новый язык. Что нового появилось в Ruby за те же годы? А?
Вы вообще следите за руби-комьюнити? написали хотя бы тысячу строк? Просто какие-то толсто-зеленые тезисы без аргументов
3. Сильная связность с окружением. PHP работает везде, на любой ОС, с любым веб-сервером и без него, не требуя ничего от окружения, кроме возможности запустить бинарник «php.exe» (условно). А еще php-fpm.
Не знаю, никогда не работал под виндой, но часто ли вы встречали приложения которые в продакшене крутятся на винде?
На всё остальное: имхо еще долго люди, вложившие 3-5-7 лет своей жизни в Руби будут сопротивляться очевидным фактам и ставить минусы в карму тем, кто констатирует давно понятный факт: Руби сдох, надо слезать…
Жаль, конечно. Но, имхо (опять же!), раз вы переходите на аргументы типа «Сперва добейся!», предмета для спора нет.
очевидным фактам
Назовите их, я, как разработчик на руби, не вижу их. Почему мне надо слезать с этого прекрасного языка? Прошу, откройте мне истину!
давно понятный факт: Руби сдох, надо слезать
Я, судя по вашему апломбу и глупости, постарше буду, поэтому позволю себе рассказать вам несколько интересных вещей. PHP сдыхал на моей памяти три раза: в 2006, когда рельсы стали похоже на продукт, в 2012 (кажется), когда нода стала похожа на продукт, и в 2014, когда все хором заявили, что теперь заживем в вебе на го. И ничё, живет, пованивает конечно, но умирать не собирается.
Не знаю, кому там и что понятно, но по статистике гитхаба все хорошо, а статистика закрытых говносайтиков безыменных говноконторок — это хорошо только девочек охмурять.
Многие профессиональные рубисты недолюбливают рельсы. Я не пишу на рельсах принципиально, работая в крупном финтехе. Пишу на руби. Много у вас там вокруг программистов, которые пишут на PHP, но принципиально не работают с фреймворками? Сомневаюсь, и могу рассказать, почему: язык слишком бедный.
Ну и, наконец, мы-то переходим с руби: внутрь эрланговой виртуальной машины, используя написанный рубистами синтаксический сахар к эрлангу под названием Elixir. А куда пойдут похаписты, когда оно окончательно сдохнет? Ой, не знаю.
А куда пойдут похаписты, когда оно окончательно сдохнет?
Не дождётесь :) А если серьёзно, то, имхо, если сохранится тренд развития последних лет, то логичным будет переход на Java/C#. С другой стороны многие пехепешники неплохо знают JavaScript, причём с последними трендами не только клиентский, но и серверный. Например, для среднего миддла ) не должно составить труда написать на javascript веб-сокет сервер, который будет шарить сессии с http-сервером на PHP и дергать его как API.
:)
Ну не все же настолько всеядны, чтобы на js переходить без анестезии. C# только кажется простым, идеологически он гораздо извращеннее php, так что не уверен. Java — про другое совсем, поломать внутри все паттерны не так-то просто (а многим еще и неохота).
Вряд ли. У серверного JS совсем другая философия, как мне показалось.
Говнокодинг не в счет.
Уважаю.
>Много у вас там вокруг программистов, которые пишут на PHP, но принципиально не работают с фреймворками?
Мало. Я один из них :) С фреймворками не работаю не то что принципиально, просто они унылые.
>Сомневаюсь, и могу рассказать, почему: язык слишком бедный.
Не знаю, мне язык не показался бедным. Библиотека PHP, наверное, самая богатая.
Недавний пример. Тут у нас у клиента на Java сломался парсер JSON, там он по ходу пишется вручную каждым программистом. :) В php же для этого всего одна функция: json_decode().
Я не про библиотеку, я про средства выразительности самого языка. Самые выразительные, разумеется, LISP и (с небольшим отставанием) Erlang. Ну вот например задача: средствами языка написать логгер, который включается только в dev-режиме, а в продакшене не добаляет ни единой лишней инструкции процессора (high-load, то-сё). На руби у меня это получилось в 20 строчек.
Даже на Java с AspectJ это гораздо более громоздко и менее интуитивно. Боюсь, что на PHP это совсем заковыристая задача.
Ну и руби позволяет писать функциональный код, а функциональный map-reduce банального массива в PHP — это же трэш и угар, натурально.
функциональный map-reduce банального массива в PHP — это же трэш и угар, натурально.
https://laravel.com/docs/5.1/collections#method-map
https://laravel.com/docs/5.1/collections#method-reduce
А также нативные методы array_map и array_reduce.
Даже если у вас эта ненависть к функциям в скобках — возьмите класс коллекций из ларавел (он легко забирается в любой другой пхп проект, так как не имеет почти никаких зависимостей) и пишите все в стиле вызовов методов к массивам. Я дал ссылки наверху на пример же, каким образом вы смотрите на мои сообщения? Просто чтобы поспорить и «пошпынять php» в очередной раз?
Да до реальных ФП с пайпами ему далеко, но вещь в виде
some_var.map(&:method).inject(&:method).something(&:method)
можно было бы придумать
PHP по другому смотрит на объекты и примитивы, это разница в идеологии и философии программирования. И при желании, вы можете использовать что-нибудь вроде вышеупомянутого мною класса коллекций из Ларавел. Никто вам этого не запрещает. Тогда вполне можно писать код в таком стиле, например:
$jsonUsersFilteredAndGroupedByCity = collect($usersArray)
->filter(function ($user) { return $user->age > 20; })
->groupBy('city_id')
->toJson();Всё-таки видно, что пришли поспорить, а не к истине придти. Мне вам доказывать теперь, что ООП — это хорошо?) Пожалуйста, пользуйтесь чем хотите, но в мире программирования, отличии от мира реального, нет Единственной Истинной Религии, если вы своими комментариями пытаетесь претендовать на это.
Я же кидал ссылки на красивые решения в своём комментарии выше :)
Прокрутил видео, да, я знаю об основах функционального программирования, об иммутабельности, и прочем. Это всё хорошо, но я не вижу причину называть ООП злом только из-за одного видеоролика на ютубе. Иначе все бы мы уже давно использовали только функциональные подходы.
Картинка мало относится к PHP, если честно. Там не так уж часто объекты зависят от состояния друг друга, так как его логика работы слишком простая: получил запрос — вернул ответ, умер. Объекты если и шарятся между компонентами, их состояние не изменяется каким-то кардинальным образом.
как там внутри красиво использовать внешнюю переменную?
Именно так, как вы и сказали — через добавление use конструкции к объявлению анонимной функции. Опять же, не вижу особых причин для обсуждения этой части PHP: это не сильно мешает при разработке.
Ну да, такой синтаксис, конечно.
Да, можно привыкнуть. Но «явное лучше неявного», вы уж меня великодушно простите, это просто вообще не про php. Не нужно пытаться из табуретки сделать велосипед. Можно привыкнуть к тому, что ноль целых ноль десятых равен символу нуля, но они по разному себя ведут под ифом, можно. Но вот не надо после этого костыль (use) называть «таким синтаксисом», ладно?
Вы сами себе и ответили.
Если в ответ на реплику о (заострите все ваше внимание, на секундочку, пожалуйста) средствах выразительности самого языка, вы сами же приводите ссылки на стороннюю библиотеку, значит с синтаксисом языка все очень плохо. И это не экзотика какая-нибудь, это map-reduce.
Расширение крутое, но будет лучше, когда подобные возможности появятся в самом языке. Это, кстати, хороший вариант и обратную совместимость сохранить ещё на пару версий и параллельно новую согласованную stdlib сделать.
- Монополия — ну, фрэймворки есть и иные, просто никто ими не занимается. Проблема кмк в том, что многие прогеры считают руби "несерьёзным и хипстерским", хотя при этом недостаточно хорошо осведомлены о его реальных возможностях(а ведь можно и небольшие десктопные приложения ваять). А рельсы убивают руби тем, что большинство на этом и останавливается, хотя у языка достаточно и иных возможностей. Например, при обработке текстов и парсинге страниц я предпочитаю короткие скрипты на руби с его Nokogiri.
По остальным пунктам сказать нечего, всё так.
З.Ы. Занимаюсь разработкой на yii и сайд-проектами на RoR. Последнее время единственным legacy стал считать проекты на RoR, ибо там такое бывает, что просто умереть не встать)
Языки программирования не могут умереть, есть мера интереса общественности к ним. Судя по рейтингу 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 сказывается отсутствие инструментов (или их зачаточное состояние) на скорость и удобство деплоя.
Про сервер приложений, автор вообще не особо понимая что пишет написал судя по всему…
Простите, а в чем проблема? В среднестатистическом AR (для примера возьмем тот, что в Yii2) с подзапросами работать более чем удобно, любой relation легко фильтруется в анонимных функциях, просто приведу пару строк из документации:
$customers = Customer::find()->joinWith([
'orders' => function ($query) {
$query->andWhere(['>', 'subtotal', 100]);
},
])->all();
при всём при том, что на рубях все фреймворки умеют просто и изящно работать локально (для разработки) из коробки.
PHP сам умеет работать для разработки из коробки. php [options] -S : [-t docroot] Всё, даже фреймворки не нужны.
но в средних и больших проектах у PHP сказывается отсутствие инструментов (или их зачаточное состояние) на скорость и удобство деплоя.
capistrano, puppet — зачаточные? )
Про сервер приложений, автор вообще не особо понимая что пишет написал судя по всему…
Как я понимаю, он имел в виду, что в PHP для создания типового сервера не нужно писать ни строчки кода, серверные функции берёт на себя среда исполнения, а приложение (для разработчика) работает по CGI, а на Ruby обычным является написание сервера на Ruby или использование написанного другими типа Thin.
в PHP модно кричать что мы реализовали AR
В PHP модно кричать «AR — отстой, DM — наше всё», имея в виду Doctrine 2.
1) им не нужен php-fpm и они его никогда его не устанавливали
2) не знают linux и не имеют опыта работы в окружении, отличном от shared хостинга
3) новички, не умеющие в чтение документации и английский язык
Все три пункта совершенно невозможны для php программиста, пишущего под тот или иной фреймворк, следовательно ваше утверждение в принципе некорректно.
По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.
На этапе разработки консоль не нужна (особенно если не отлаживать), а деплой и автоматизировать можно.
Зачем устанавливать и удалять composer пакеты при разработке? Неужели отсутствие пакета помешает открыть Блокнот и поправить пару файлов?
Смысл в том, что у аудитория этой статьи (людей, перед которыми может встать выбор Rails\условный Symfony) в любом случае имеются навыки как работы с консолью, так и настройки окружения, это просто повседневная задача.
Потому меня слегка удивляют утверждения, что человек продолжительное время использующий cli для разработки и деплоя что-то там не может настроить на сервере.
В этой ветке обсуждалась не "аудитория статьи", а "средний видимый PHP-программист".
И речь шла именно о том, что полно PHP-кодеров, которые не используют cli для разработки и деплоя.
Спасибо, это прекрасно.
Не хотел портить вам статистику по тем, кто воспринимает все за чистую монету, но не смог сдержаться, простите :)
Деплой у нас был через CI(Bamboo). Разработчику нужно было закоммитить изменения git repo и написать миграции для БД.
Относительно деплоя — трогать .htaccess или настраивать проект под окружения должен именно тот — кто конфигурировал CI, остальных разработчиков эта задача не должна затрагивать от слова совсем. Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm».
Другими словами — вы описываете случай, совершенно невозможный при адекватном разделении обязанностей, к качеству php разработчиков это имеет довольно мало отношения.
В файле .htaccess, по сути, в виде modrewrite-правил записываются основные входные точки для приложения — а потому заниматься им должен именно что разработчик.
Просто потому что проще самому написать эти самые правила, чем объяснять админу их на словах.
Ничего общего с настройкой проекта под окружение это не имеет — потому что эти правила будут одинаковы во всех окружениях.
Если человек пишет какой-то зависящий от окружения код или конфиги — он должен быть в курсе этого окружения. Если рассматривать ваш пример (с админом) — то последний должен был выкатить подробное readme, что делает невозможным вышеописанный случай.
В файле .htaccess, по сути, в виде modrewrite-правил записываются основные входные точки для приложения — а потому заниматься им должен именно что разработчик.
Этот разработчик должен быть в курсе в каком окружении работает его проект. Он должен быть в курсе, что проект крутится под апачем, что использование .htaccess настроено в принципе и конкретно в тех местах, где он его пишет. Либо админы должны быть в кусре ожиданий разработчика о среде исполнения и настроить её для него.
Либо ему админы должны ткнуть пальцем куда и в каком формате ему настраивать точки входа, либо он должен ткнуть пальцем для админов, где лежать конфиги, сообщить чего этого конфиги и поставить задачу сделать так, чтобы они работали.
Бывает, что на проект взяли нового разработчика, который вообще не в курсе, что существуют какие-то окружения кроме "дефолтного" apache + mod_php — а потому не видит необходимости спрашивать.
Если разработчик адекватен, а коллеги не ленятся объяснять — то эту ошибку он сможет допустить ровно 1 раз в жизни. Но от одного раза не застрахован никто :)
Если допустить, что незнакомый с особенностями используемой инфраструктуры человек идет что-то перенастраивать — он как
Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
он как минимум должен внимательно прочитать readme, где будет русским по-белому написано «используется php-fpm»
Как показывает практика, документация практически всегда устаревшая, это не только в маленьких но и больших компаниях.
Другими словами — вы описываете случай, совершенно невозможный при адекватном разделении обязанностей, к качеству php разработчиков это имеет довольно мало отношения.
Я описываю случай, который я лично наблюдал и тут дело не в разделении обязанностей, а в компетенции специалиста.
Вот еще один момент вспомнил, когда разработчик хранил cache, php сессии в memcached(Не спрашивайте, зачем он это делал, но это было так), очищал его (memcflush --servers=localhost:11211) искренне удивлялся тому, что у него слетала авторизация в локальном проекте.
Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
Кто ему поднимал это дев-окружение? Почему оно оказалось отличным от продакшена? Если сам, то на основании чего? Устаревшей документации?
а) не является фреймворком общего назначения
б) не является альтернативной rails
Да, вполне возможно описанные вами проблемы могли возникать, но это другой мир с другими программистами и совершенно иными типами проблем. Для аудитории статьи сложности в вопросах настройки «php-fpm» просто нехарактерны, о чем я и писал выше.
> Он не перенастраивает, а добавляет и проверяет свой функционал, который крутил у себя в dev окружении
Которое должно автоматически развертываться и быть одинаковым для всех разработчиков.
> Я даже больше вам скажу, большая часть PHP разработчиков не в состоянии определить, в каком режиме работает PHP. По старинке пишут реврайты, php_value, etc в .htacess, два часа дебажат и в конечном итоге узнают то, что проект поднят на PHP-FPM.
Почему не в состоянии?
1) сервер настраивал нехороший человек, который не утруждался документированием
2) деплой настраивал не менее плохой человек
3) при этом на разработчика повесили задачу, зависящую от окружений, ни о чем не уведомив
Это не является ни проблемой программиста, ни его косяком, и тем более — такое не стоит приводить в пример, как типичную ситуацию.
Согласен. Я это постоянно говорю. Но илита загоняет меня в минуса и ридонли :)
>А настроить разные среды с разными версиями в пределах одного сервера для PHP нетривиальная задача.
Я руками с исходников себе ставил.
Или пользуйтесь шаред хостингом.
И обновлялся практически бескровно 5.2-5.3-5.4-7.0
>Из нескольких десятков пхпшников что я знаю ни один не сможет поднять php-fpm (упомянутый выше) хотя бы за один день.
На винде оно какое-то кривое стало с 2009 года, поэтому пользуюсь OpenServer. Я в 2008 как новичек все сам поднимал без проблем.
П.С.
Пробовал также и руби, ставил редмайн. :)
>«крутые» и разнообразные ООП фреймворки на PHP жутко тормозят
Согласен. Я это постоянно говорю. Но илита загоняет меня в минуса и ридонли :)
http://govnokod.ru/19878
Ваше мнение и гроша ломанного не стоит, т.к. вы некомпетентны совсем, или же уже 3 аккаунт тупого тролля (не жирного, именно тупого, который показывает недостаток наличия аккаунтов без инвайта с возможностью что-то комментировать)
Про то, что rails плох — пусть хотя-бы один пхп фреймворк будет настолько плох и он станет лучшим пхп фреймвоком из существующих. Серьезно, планка поднята очень высоко и не смотря на серьезные архитектурные проблемы rails все еще живее всех живых
Да даже упомянутый asset pipeline — какие фреймворки из коробки имеют настроенный сборщик ассетов? Ведь оно все равно надо а настраивать это не так тривиально (нужные разные правила для разных окружений, надо уметь hot reload в дев, source maps etc) — зачем тратить тысячи человекочасов на повтор такого раз за разом. Рельсы берут такими вот мелочами — когда за тебя решены вопросы которые все равно придется решать
Про то, что переходить некуда — уже есть. Зовется Phoenix (язык — elixir). Делают люди из команды rails. И таки разработчики на него уже переходят т к все основные проблемы рельс успешно решены. Всячески рекомендую.
Хосе — не «люди», и он никогда не работал в «команде rails».
José Valim — http://contributors.rubyonrails.org/ — #5 по количеству коммитов.
Пусть будет не "в команде" а core contributor тогда
Contributor — это безусловно. Просто там же очень много политики, как раз вокруг Elixir’а, и мне показалось, что на этом имеет смысл заострить внимание.
В смысле, я про идеолога DHH и его свиту :)
на самом деле dhh всего лишь один из контрибуторов, но с правом вета. и такие нужны в любом проекте
Нет. DHH — это и есть команда рельс. И именно поэтому, в частности, мы имеем то, что имеем: Elixir, придуманный не от хорошей жизни (насколько мне известно, перед Хосе не стояло никакой практичесой задачи), Solnica, воюющий с ветряными мельницами, плодящиеся адовые коллбэки в AR, откровенные костыли в корке, GFY в твиттере и т. д.
Почитайте любой тред с участием DHH.
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 научились программировать, и в рейлсах слишком много курсов «программист за неделю».
3) веб за это время поменялся, rails зафейлил поддержку этих изменений:
3.1) веб-сокеты — поддержка заявлена, но лично у меня не взлетело за несколько дней, когда было нужно, пришлось по другому делать
Какой-то странный аргумент, а у меня сразу все взлетело :)
3.2) api-only server side — только сейчас выпускают rails 5 с этим, но оно какое-то ущербное
А почему ущербное? И вообще, только API на рельсах можно было писать и до выхода rails 5
3.3) микросервисы — вроде бы не мешает, но памяти есть слишком много, если дробить на микросервисы
Из всех этих утверждений согласен только с 3.3, хотя тут тоже зависит от реализации
1. Удобство поддержки. Жестко определенная структура папок проекта, нейминга дало мне возможность не только быстро анализировать чужие коды, но и вспоминать через полгода «что ж я тут понаписал». В случае с PHP — развитие моих девелоперских навыков мешало мне понять старый код и требовало времени и усилий разобраться в нем.
2. Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
3. Удобное из коробки разделение на среды: development, test, production
4. Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Меня периодически друзья просят посмотреть MODx, сайты на Symphony, но для меня это каждый раз сильный стресс. Нет ощущения — что сейчас полезу в проект, и буду знать, где какие части найти. Ну и плюс каждый раз после такого опыта радуюсь, что имею возможность писать именно на Rails или на чистом Ruby (есть собственный framework для CLI-приложений, не использующий Rails).
Жестко определенная структура папок проекта,
Ну не знаю… Кто то диктует вам структуру папок в вашем проекте?
Более чистый синтаксис. Видеть User.firstname мне гораздо приятнее и проще для восприятия чем $user->firstname()
Дело привычки же. Да и скобки лишние. А IDE сделает все за вас.
Очень четкая и прозрачное разделение на контроллеры, модели, виды.
Мне кажется в любом языке четкое разделение. Тем более это разделение можно организовать как угодно и тем более это не проблема языка.
Вы это про inline код в php? многие даже почему то считают это best practices. Мол нам шаблонизатор не нужен, у нас php шаблоны! быстро же!
Мне кажется в любом языке четкое разделение.
Скорее ровно наоборот, ни в одном (мэйнстрим) языке нет такого разделения. Разделения вносят (если вносят) фреймворки, а чаще вообще соглашения разработчиков типа: «пишем по MVC, контроллеры туда, вьюшки сюда, модельки там лежат».
upd. действительно, читал оригинал
Вы должны сначала создать прочную ООП конструкцию, а уже потом упрощать её с помощью DSL.
Конечно, весь мир в последние 10 лет как раз работает над упрочением ООП конструкций.
Я сначала хотел надергать очень смешных цитат, но потом решил, что тогда придется каждое предложение из заметки комментировать.
Поэтому скажу главное: если вглядеться в то, что сейчас делает Piotr Solnica, многократно цитируемый в статье, то это (сюрприз) не переход на PHP. И не переход на Node/Go/Rust/Buzz. И даже не на Elixir, который, надеюсь, постепенно вытеснит рельсы — не потому, что такой прямо ух, а потому, что запускается внутри бима. Так вот, Петр — отчаянный руби-евангелист, и приводить его тезисы против рельс (а часто — и те, кто в теме, прекрасно это знает, — лично против DHH) в качестве аргумента в пользу «руби уже не торт» — может либо очень глупый и несведущий профан, либо злонамеренный подтасовщик. Автор заметки, судя по всему, из первых.
Руби код в 20 раз лаконичнее и выразительнее подавляющего большинства современных языков. Конкуренты у него в этой области — разве что эрланг и отчасти лисп. И поэтому большинство успешных проектов, которым нужно было быстро взлететь без заметных инвестиций его выбирали. Он не лучше, не хуже, он короче.
Для высоконагруженных систем не годятся ни руби, ни пхп. Но до высокой нагрузки в 99% процентах случаев есть время и ремурс все переписать правильно.
Поэтому мне странно в сто пятьдесят первый раз читать сравнительные статьи. Это как если бы Вася опубликовал длинную статью о своей возлюбленной, а тут пришел бы Петя и стал с ним спорить: нет, моя лучше. Одинаково хороший и одинаково безобразный код можно напистаь на абсолютно любом языке программирования.
А что годится? Сайты на с++? :)
То же самое и с разработчиками на PHP-фреймворках…
Но это ведь проблемы не языка, а сообщества. Рельсы инструмент, написанный на Руби. Если сделали кривой молоток, то проблема не в стали, а в инструменте и его производителе.
Чем еще объяснить фактическую монополию Рельс?
Та ну вас нафиг, я не буду тут писать комменты
И никто не угадал — на смену PHP идет JS (скажите спасибо node.js). Я вот даже не знаю, что по этому поводу можно сказать, потому что JS, на мой взгляд, гораздо хуже PHP, как язык.
А лет через пять посмотрим.
Node.js требует более высокого порога входа всё-таки. Асинхрон, сложности с пониманием и продумыванием архитектуры проекта, с которой до сих пор не сложилось каких-то "лучших практик". Нода штука прикольная, но туда просто так залезть, как на территорию PHP — просто не выйдет.
> 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).
хотя он тоже уже потихоньку обрастает макросами
Макросы Elixir — это чистый AST, и это его основная killer feature. Макросы не могут сделать код эликсира менее читаемым по определению. И, для вашего сведения, 95% основных операторов в эликсире (включаяcase, иunless— макросы.)
И, для вашего сведения, 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. Скорее всего просто у меня мало опыта с этим.
А я не говорю, что это секрет, я просто удивился фразе «потихоньку обрастает макросами».
Macros should only be used as a last resort.
А вот это — чистая защита от нубов. Точно так же, как про руби все пишут: «не используйте манкипатчинг!», а на деле — основной смысл руби в манкипатчинге, просто его нельзя давать в руки обезьянам :)
В эликсире всегда свежая актуальная версия utf-8 именно потому, что Валим принял гениальное решение: он макросами парсит актуальные файлы консорциума с описанием глифов.
Для понимания макросов лучше всего не полениться и прочитать Metaprogramming Elixir Криса Мак Корда (создателя Финикса). Все вопросы отпадут.
Привет из мира JavaScript:
плюрализм это хорошо, говорили они
будешь учить по фреймворку в неделю, говорили они
Экосистема Ruby (on Rails) с горьким привкусом, или «Как мы любим пошпынять PHP»