Я должен учесть предупреждения Derek Sivers о миграции с PHP на направляющие? [закрытый]

Austin Ziegler записал интересный ответ на ту статью:

По возврату Derek Siver к PHP …

Суть его:

1. Derek выбрал технологию по неправильным причинам. Он выбрал его частично на основе шумихи направляющих, но он предположил его как серебряную пулю, которая волшебно подаст его заявку лучше просто, потому что это находится в направляющих.

2. Направляющие не соответствовали прикладной модели Derek для Ребенка CD, и прикладная модель Derek более важна, чем технология, которая будет использоваться, так как она представляет бизнес, который он понимает хорошо.

3. Он проигнорировал своих существующих экспертов для новой технологии. Ни он, ни его сотрудники не знали Ruby в стороне, возможно, от проигрывания вокруг с ним. Это не было технологией, которая, как считали, была соответствующей на основе опыта; это было технологией, которую считает соответствующей управление (жаль Derek, Вы могли бы все еще пачкать руки с кодом, но Вы - все еще управление).

4. Derek приблизился, земля в-целом-среды проекта переписывают с Одним развертыванием Важного дня, не рассматривая способы постепенно вводить его со временем. Почти всегда возможно найти интерфейсные точки, где можно заменить один лом за один раз. В конечном счете это - то, что люди направляющих wouldshould говорят Вам так или иначе: замените одну область за один раз, каждого с различной кодовой базой. Соедините интерфейсом с ними как с УСПОКОИТЕЛЬНЫМИ сервисами. Не заставляйте их зависеть от схемы единой базы данных.

Недавнее сообщение Luke Crawford о Muxtape предлагает другую перспективу.

Я провел свои первые 4 года как веб-разработчик, использующий PHP, и это была забава в то время, но когда я начал понимать, как сильно неэффективный это было, я начал смотреть в другом месте. Я отказался от своего традиционного образования информатики для сети и ее больших возможностей дизайна, но из-за этого я знал, что был лучший путь. Разработчики PHP не должны быть высмеяны так же, как они часто - то, потому что, откровенно говоря, это позволяет людям без более строгого фона выполнить удивительно технические вещи. Это должно удовлетворить компьютерных фанатов, но обычно превращается в некоторую слабую вещь 'мужественности' вместо этого. Так или иначе эта неудовлетворенность началась в конце 2004 года, и Ruby on Rails был совершенно нов, стабилен, и обратился к каждому ограничению, которое я столкнул со своей старой платформой PHP MVC собственной разработки. Я исключительно сделал работу направляющих с тех пор.

В любом случае было бы трудно защитить категориальный оператор "Rails does not offer any significant advantages over PHP".

PHP является большим инструментом для решения определенных проблем. Направляющие являются большим инструментом для решения определенных проблем.

И как активные направляющие и как разработчик PHP (с опытом, возвращающимся к 2000), я категорически не согласен с оператором.

Я поддерживаю тот Ruby предложения значительные преимущества перед PHP, и направляющие являются лучшей платформой, чем что-нибудь в мире PHP. Многое из этого имеет отношение к самому языку - Ruby может сделать вещи, что PHP просто не может. Однажды Вы grok элегантность метапрограммирования, совершенно новый уровень выразительности открывается до Вас.

У меня есть опыт с PHP & Ruby + Ruby on Rails (заработанные деньги с помощью обоих, но не много).

Библиотека Ruby намного лучше. Библиотека PHP является набором функций в глобальном пространстве имен с непоследовательными именами и порядком аргументов. strpos по сравнению с str_repeat. strposпервым аргументом является большая строка, и вторым аргументом является строка для нахождения. explodeпервым аргументом является строка для разделения, и вторым аргументом является большая строка. Это было большой проблемой для меня. Я должен был искать много вещей при использовании PHP, но не при использовании Ruby. Я могу помнить вещи, потому что они последовательны. Названия методов ясно дают понять порядок аргументов. Другой: PHP's strlen($str) по сравнению с count($arr) в то время как в Ruby это справедливо anything.length.

Ruby язык лучше, чем PHP. Это имеет закрытия, хорошее OO, хороший синтаксис (это субъективно, но Вам нужно намного меньше пунктуации в Ruby, и это - то, что я чаще всего понимаю превратно).

Это - мой опыт. Попробуйте обоих и посмотрите что работы для Вас.

Направляющие являются хорошей платформой, но иногда миграции являются плохими идеями. Я предпочитаю запускаться с нуля, Вы не можете "переводить" код PHP в контекст направляющих. Это просто не может быть сделано, главным образом из-за самого языка Ruby и шаблона MVC.

Отказ от ответственности: Я ни в коем случае не эксперт по направляющим или Ruby.

Как кто-то, кто был в промышленности для почти в 15 лет, я вижу несколько предупредительных знаков, которые делают меня озабоченным Ruby on Rails конкретно. Я собираюсь проигнорировать язык здесь, потому что язык является языком. Ruby является современным языком с закрытиями, исключениями, OO, и т.д. Некоторые критикуют его относительно производительности. Эти проблемы в основном не важны в этом, они не влияют на производительность реального мира (если требуется 300 мс, чтобы загрузить и отобразить Веб-страницу, кто заботится, что серверные коды берут 10, 20 или даже 30 мс для выполнения?) и переходный в этом они фиксируются в более поздних версиях (как, кажется, имеет место с Ruby 1.9).

Ruby on Rails является закрытым, тяжелым стеком. Я имею в виду это как наблюдение не обвинение. Это тесно интегрируется (включая с Прототипом) во многом как Шов JBoss в мире Java (интегрируемый плотно с JBoss/Hibernate, и да я знаю недавние выпуски, и статьи занялись проблемой использования его с, скажем, Glassfish и другим поставщиком JPA),

Это может быть и хорошей вещью и плохой вещью. J2EE, например, будучи довольно открытым стеком был причиной для больших инноваций в промышленности программного обеспечения в прошлое десятилетие, когда почти каждая часть его (особенно EJB) была заменена различными проектами, которые могли быть вставлены вместе. И конечно это было, если не место рождения для Spring, это был, конечно, инкубатор.

С другой стороны, Вы больше закрыли стеки как .NET, где их закрытый характер допускает быстрые инновации, модель Microsoft (обычно) выделялась в. Через несколько коротких лет DirextX пошел от того, чтобы быть шуткой к завершенному строгому наказанию OpenGL как игровая платформа разработки, потому что любая закрытая система может развить это намного быстрее, чем открытая система стандартов. Это, как это работает.

Другой важный момент, который я упомяну, - то, что в последние годы было перемещение к ORMs ("объектно-реляционное отображение") в Java, .NET и в другом месте и это - часть импульса позади направляющих. Я прокомментировал это ранее, например, "Используя ORM или плоскость SQL?" и я не повторю те точки в их полноте.

Поскольку большинство из Вас знало бы, что существует несоответствие между объектными и реляционными мирами, которые ORMs стремились соединить мостом. В прошлом году или два я имел дело с этим главным образом через Java (JPA конкретно).

Теперь, когда Вы образуете мост между двумя вещами, которые не соответствуют Вам, заканчиваются с "текучими абстракциями" (как Joel выразился):

Все нетривиальные абстракции, до некоторой степени, являются текучими.

Теперь то, что я добавлю, является этим: существует обратная связь между сложностью абстракции и насколько текучий абстракция. Рассматриваемый вопрос: ibatis. Ibatis является чрезвычайно легкой все же мощной платформой персистентности для Java, и один я - огромный поклонник. Это переносит SQL во внешние файлы и к тому же помещает многих современное поведение ORM, такое как:

• Ленивая загрузка отношений;
• Отображение результата;
• Группировка результатов к нескольким уровням (что-то JPA не может сделать); и
• Различаемые типы (т.е. тип определяется данные).

Я оценил бы, что ibatis имеет 90-95% функциональности, в спящем режиме с единственной сложностью, наверху являющейся улучшением байт-кода во время выполнения для ленивой загрузки через cglib (JPA делает это тот же путь) с единственным недостатком, что необходимо записать собственные запросы (и я не полагаю, что серьезная оборотная сторона, но opnions будет варьироваться).

Сравните это с поставщиком JPA, который полагается на инструментарий, время загрузки, переплетаясь и нестандартные загрузчики класса для реализования той дополнительной 5-10%-й функциональности (и абстракция является все еще текучей).

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

Возвращение этого к направляющим: текучим аргументом абстракции является моя самая большая проблема с философией направляющих.

То, что также вызывает тревогу для меня, является комментариями, как которые Вы входите в сообщения По Возврату Derek Siver к PHP …:

• "Derek выбрал технологию по неправильным причинам".: ожидайте..., действительно ли RoR не является или Платформа веб-приложений общего назначения или достаточно близкое факсимиле? При этом, почему Вы не можете сделать сайта как CDbaby в нем?
• "Направляющие не соответствовали прикладной модели Derek для Ребенка CD": Как так?
• "Он проигнорировал своих существующих экспертов для новой технологии".: ожидайте... разве, он не нанимал эксперта?
• "извините Derek, Вы могли бы все еще пачкать руки с кодом, но Вы - все еще управление": Я соглашаюсь с комментарием, что эта кавычка "глупа" и добавит что его вводящее в заблуждение, несоответствующее и возможно strawman;
• "Derek приблизился, земля в-целом-среды проекта переписывают с Одним развертыванием Важного дня": возможно не желательный, но если Вы готовы провести время и деньги на нем, я не рассматриваю его как причину, почему Вы не можете сделать сайта в RoR.

Теперь 5-7 лет назад, когда EJB был расшевелен, Вы получили критические замечания его на основе большого количества вещей, и Вы получите рослых защитников, спорящих:

• "Приложение X не соответствовало модели EJB";
• "Они не поняли, как EJB работает";
• "EJB не для всех приложений" (они признали бы поражение на этом, чем столкнулись бы с более явной проблемой, что это действительно не подходит уже не говоря о хорошей идее для, ну, в общем, примерно ничего);
• и т.д.

Так сообщения анти-Ruby (и особенно их опровержения) весь звук, очень знакомый мне.

Стоит упомянуть, что направляющими "Напыщенной речи года является Гетто" Zed Shaw, который является 6 000 нечетной напыщенной речи слова ("пожарище" является, вероятно, лучшим словом) против направляющих. Некоторые известные кавычки:

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

и

Заметьте, как мне потребовались несколько секунд для ответа. Этот отдельный оператор в основном означает, что все мы были обмануты. Основное приложение направляющих, что DHH создал требуемый перезапуск _400 раз. Это - производственное приложение, которое не может не лечь спать больше 4 минут в среднем.

и (на утечках памяти):

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

и

Большая часть обо всем этом существует потенциально 10 новых веб-платформ, которые могут взять направляющие. Черт, порожденная Полукровка или помогла 5 из тех. Моим фаворитом тех платформ является Merb, который является буквально “Полукровкой плюс Erb”, но теперь он использует Erubis главным образом. То, что я люблю в Merb, - то, что оказалось, что Вы могли сделать быструю ориентированную на многопотоковое исполнение веб-платформу Ruby со всем одинаковым идеями как направляющие и использующий большую часть механизма направляющих одновременно. Однако шутка - то, что перед Merb идиоты Ядра направляющих кричали бы вверх и вниз по Вам, не может сделать направляющие ориентированными на многопотоковое исполнение. Ezra однако доказала их неправильно просто пишущий лучшие направляющие, чем направляющие и все благодаря Полукровке, являющейся настолько легким взломать и работать с.

и:

Ruby on Rails стал полным людей как Koz с Koz самый старший из присяжных острословов подражателя. Koz стал удачливым в лучшем случае и ввел его поганое кодирование в хороший проект, испортил его и затем фиксировался на безопасности как способ получить больше контроля. Конечно, он ничего на самом деле не знает о безопасном кодировании, которое является, почему его код, кажется, имеет много ошибок (пойдите, проверяют дерьмо парсинга даты. Подсказка: месяцы не всегда имеют 30 дней).

И, хорошо это продолжается.

Таким образом, я предполагаю, что могу суммировать его этот путь: Направляющие плохо пахнут.

Я переписал бы его в направляющих, но если Вы любите PHP, пойдите с PHP. Не заботьтесь о том, что говорят другие люди, сделайте любые иски Вы.

В бизнесе время - деньги, и иногда нужно идти по пути наименьшего сопротивления. Никакая среда, язык, структура и т. Д. Не идеальны. Учитесь и используйте то, что хотите, и держите это в покое, друзья !!!!

Я прочитал сообщение от Дерека Сильверса. В этом есть что-то странное. Он рассказывает историю о проекте, который вышел из-под контроля, затянулся на несколько месяцев и в конечном итоге от него пришлось отказаться. Он винит в этом фреймворк Rails. Однако он никогда не говорит, что именно в Rails привело к провалу проекта. Статья была бы гораздо более убедительной, если бы он предлагал некоторую достоверную информацию, но он не упоминает ни одного конкретного места, где Rails его подвел. Самое близкое, что он подходит, - это сказать, что их «потребности» (?) Противоречат предпочтениям Rails (какие? Как?)

Между тем люди во всем мире (включая меня) реализуют сложные веб-приложения в разумные сроки. с использованием Ruby on Rails.

Учитывая отсутствие деталей или вообще какой-либо конкретной технической информации, в статье Дерека, легко могло случиться так, что проект потерпел неудачу по ряду причин, не имеющих ничего общего с Rails.

Первоначальный вопрос был: «Следует ли мне прислушиваться к предупреждениям Дерека Сильверса о переходе с PHP на Rails?» Я бы ответил нет, его «предупреждения» равносильны расплывчатому анекдоту без каких-либо подтверждающих доказательств. Их совершенно безопасно игнорировать.

Стоит ли переопределить PHP-приложение в Rails? Это другой вопрос. На этот вопрос нет однозначного ответа. Это полностью зависит от обстоятельств.

Стоит ли переопределить PHP-приложение в Rails? Это другой вопрос. На этот вопрос нет однозначного ответа. Это полностью зависит от обстоятельств.

Стоит ли переопределить PHP-приложение в Rails? Это другой вопрос. На этот вопрос нет однозначного ответа. Это полностью зависит от обстоятельств.

Лучший ответ даст сам автор. Похоже, он снова возвращается к RoR!:

Предисловие

Моя бывшая компания (CD Baby) была одной из первых, кто громко перешел на Ruby on Rails, а затем еще более громко перешла обратно на PHP (погуглите меня, чтобы прочитать об этой драме). Эта книга Майкла Хартла была так высоко рекомендована, что я должен был попробовать, и Ruby on Rails Tutorial - это то, что я использовал, чтобы переключиться обратно на Rails снова.

http://railstutorial.org/book

И просмотр его собственного сайта, действительно, доказывает его возвращение к RoR:

Вместо того, чтобы пытаться научить всех моему уникальному PHP-фреймворку, все проекты будут стандартизированы на Rails 3.

http://thoughts.pro/

Ребята, которые перешли с Rails на PHP, просто следуя его известной статье, теперь пришло ваше время вернуться к Rails, снова!